Better error handling in env var parsers

[workanator]

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.

[filipegoncalves]

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:

• Permissive, but strongly typed - for example, if $"FOO"::int isn't defined, we return 0, but if on the other hand $FOO does exist but is not a valid integer, we return an error
• Permissive, but weakly typed (or, not typed at all) - if $"FOO"::int isn't defined, return 0; if it is defined but is not a valid integer, also return 0
• Restrictive, strongly typed - If undefined, return an error immediately. If invalid, return an error.
• Restrictive, weakly typed - If undefined, return an error. If invalid, return the default empty value for that type.

Of course, with ::auto there isn't a distinction between permissive strongly typed and permissive weakly typed (we just infer the correct type in the first place); ditto for the restrictive versions.

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 $"FOO" as a local configuration variable, if not defined, search as an environment variable), but this is a topic for another discussion - but it certainly plays a role in how we do error handling with non-existent / invalid environment variables.

More to come in the following days (probably something to work on over the weekend), but this looks reasonable.

Thoughts?

[workanator]

Regarding to strongly/weekly typed I'm thinking of two options:

• User asks when strogly typed value is required, e.g. $"FOO"::int! - strong, $"FOO"::int - weak.
• User asks when weakly typed value is required, e.g. $"FOO"::int?- weak, $"FOO"::int - strong. I believe the option with the exclamation make more sense because we say "Give me that FOO as int!" :)

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. Other option is to implement simple functions and when we need $"FOO"::int or a default value if env var is empty then we can do say COALESCE($"FOO"::int, 99).