Feature Request: surface errors instead of warnings/swallowing

[posita]

In some cases, one might want to reject entirely an environment file that is un-parsable (e.g., to avoid unintended side-effects from a partial configuration or dotenvs internal attempts to make sense of things).

Is it possible to surface errors to a caller (e.g., a creator of DotEnv) somehow? I'm thinking of something like:

try:
  DotEnv(path_to_env, …, raise_on_parse_error=True)
except DotEnvParseError:
  logging.error(f"Couldn't parse {path_to_env}!")
except FileNotFoundError:
  logging.error(f"Couldn't find {path_to_env}!")
except PermissionError:
  logging.error(f"Couldn't read {path_to_env}!")

[cosama]

I just run into a similar issue. If using this as a library then having error raised is essential in some cases. Personally, this could also be addressed by changing logging.warning calls to warning.warn calls, those could be caught (with a little bit of additional efforts) as well. Happy to work on this (raising Errors or warnings) if the developers here agree that this would be a welcome change.

[theskumar]

Related/Duplicate:

• requireFile option for strict checking of env file existence #297