Closed GMKrieger closed 1 year ago
One thing about error treatment that I'd like to see is to see the to-be-loaded config before the error.
Sometimes if I define a configuration value that's not valid, I get the error about the value being wrong and I don't see what's the configuration that's problematic.
For ex.:
indexer
thread 'main' panicked at 'Dapp json read file error: Os { code: 2, kind: NotFound, message: "No such file or directory" }', rollups-events/src/rollups_stream.rs:49:45
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I get this error, that's not a good error message, but I don't see the whole configuration that was used by the indexer to start.
I'd be satisfied with an error message informing the exact CLI argument/environment variable that failed, but seeing the configuration before the error is a greater solution IMO.
Ok, so just we're clear on what you want: when there's an error that comes from the value of a config, you want to be informed what config is raising the error and the value stored in it, is that it?
One thing about error treatment that I'd like to see is to see the to-be-loaded config before the error.
Let's solve that in another issue. I will create it later.
📚 Context
Node services use different error handling crates and different approaches to error handling in general, e.g. the dispatcher uses anyhow and the indexer uses snafu.
✔️ Solution
Implement snafu as the error handler crate on all services and standardize the error generation and messages as much as possible.
📈 Subtasks