-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better error handling in env var parsers #14
Comments
I agree that this is something we can work on and the division between restrictive and permissive makes sense. From my perspective there are mainly 4 different scenarios:
Of course, with The challenge is to make it easy to have any of this kind of parser in configurations without making the syntax a pain (and also, we should think if all 4 of them make sense). I was also thinking that it could be useful to add configuration-scoped variables, and that these could override environment variables (so something like, first search for More to come in the following days (probably something to work on over the weekend), but this looks reasonable. Thoughts? |
Regarding to strongly/weekly typed I'm thinking of two options:
About the local config variables I'm not sure. Everything here depends on how they will be implemented. I mean syntax and other rules. But local variables may be good if we have conditional configuration when we can do some test right in the config and then assign the value to the local variable depending on results. |
Hello,
per our conversation in the mean pull request I started to think more on error handling in env parsers. Probably you are right and that will be good to return an error saying "Environment variable A is undefined" but with some rules. We can divide parsers to permissive and restrictive. Permissive parsers return the default value if the env var is empty. Restrictive parsers return the error if the env var is empty or if the env var cannot be correctly parsed. Dividing the existing parsers in those groups we have:
Permissive:
$"SOME_VAR_NAME"
Restrictive:
$"SOME_VAR_NAME"::auto
$"SOME_VAR_NAME"::bool
$"SOME_VAR_NAME"::int
$"SOME_VAR_NAME"::flt
$"SOME_VAR_NAME"::str
But it's good to have say permissive boolean parser so we need an additional syntax, for example we can add question after the type -
$"SOME_VAR_NAME"::bool?
.Those are just thoughts. The idea of env var parsers becomes more complex and maybe the idea on permissive and restrictive parsers is excessive.
The text was updated successfully, but these errors were encountered: