Skip to content

Feature Request: surface errors instead of warnings/swallowing #372

Closed
Closed
Feature Request: surface errors instead of warnings/swallowing#372
Labels
duplicate

Description

@posita
posita
opened on Jan 14, 2022

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}!")

Activity

  1. cosama commented on May 6, 2022

    @cosama
    cosama
    on May 6, 2022

    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.

  2. theskumar commented on Jun 5, 2022

    @theskumar
    theskumar
    on Jun 5, 2022
    Owner

    Related/Duplicate:

  3. theskumar
    closed this as completedon Jun 5, 2022
  4. theskumar
    added
    duplicate
    on Jun 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    duplicate

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions