The way how `secondarySources` are used in `status-im/nimbus-eth2`,
they call `addConfigFile` again which may raise `ConfigurationError`.
When that happened, loading the primary config file didn't result in
`fail`, which differs in error handling from errors within itself
as opposed to within `secondarySources`. To keep callers concise,
apply same error handling behaviour regardless of whether the error
occurred during primary or secondary sources processing.
Avoid Nim 2.0 warning in callers of `confutils.load`.
```
Warning: 'loadImpl' is not GC-safe as it performs an indirect call via 'secondarySources' [GcUnsafe2]
```
When `COMP_POINT` is invalid or out of range, return an empty list of
completions instead of raising `ValueError`. This matches behaviour for
`comp_point < 0 or comp_point > len(comp_line)` cases.
We currently return `@[]` in `splitCompletionLine` when there is
unexpected or unsupported input via environment variables, but let
exceptions during parsing propagate to the caller. Catching those
exceptions allows the caller to use same behaviour regardless of
the nature of unexpected input (either through env, or parsing).
Currently, callers don't seem to be aware of the exceptions, so
going with the behaviour used for environment errors of returning `@[]`.
Value parsers are currently allowed to raise `CatchableError`, but in
practice only `ValueError` is raised. Restrict to `ValueError`, and also
properly convert them to `fail` / `ConfigurationError` if applicable.
* suppress unreachable string format errors
We use `%` and `&` to format some strings, which may raise `ValueError`
if the format string is weird. As we are using them in ways that should
always succeed, catch those `ValueError` and convert to asserts.
* add `{.raises: [].}`
The `appInvocation` template in `confutils` is used while showing help,
e.g., before quitting. To ensure that `quit` actually happens, it can't
raise exceptions. Fix that by falling back to `""` on `OSError`.
`writeLine` can fail with `IOError`, and `styledWrite` when using colors
also with `ValueError`. To ensure that the control flow is unaffected,
simply ignore those errors while writing human-readable output to fds.
- The config files processing was not taking into account the `name`
pragma of the configuration object fields.
- The required fields were not searched within config files before
reporting an error that they are missing.
- Fields with the same names were not supported in different case branches
- The loaded config file path can now depend on the configuration
supplied through the command-line.
you can still set the value of a hidden option,
it just dont show up in the help text.
but using `ignore`, the is no chance you can set the value from cli.
line break char: '\n', '\r'
example:
-x, --name regular description [=defVal].
longdesc line one.
longdesc line two.
longdesc line three.
why additional pragma?
- to keep the default value not too far away from the 'name'.
Etan Kissling
tersec
Adam Uhlíř
jangko
Vaclav Pavlin
Zahary Karadjov
Kim De Mey
Luke
Jacek Sieka
Miran
Ivan Yonchovski
Zahary Karadjov
Ștefan Talpalaru