Standardize error treatment

GMKrieger commented 1 year ago

📚 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

[ ] Implement snafu on all services.
[ ] Standardize error messages across all services when referring to the same or very similar problems.

endersonmaia commented 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.

GMKrieger commented 1 year ago

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?

gligneul commented 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.

Let's solve that in another issue. I will create it later.

cartesi / rollups