Migrate from anyhow to color_eyre

[Antosser]

Imo, we should migrate from anyhow to color_eyre
There are several reasons for this decision:

1. color_eyre is a drop-in replacement for anyhow: You don't have to re-learn anything to be able to write it
2. color_eyre is way prettier than anyhow: See examples in feat: Switch to color_eyre and remove unneeded .unwrap()s #426
3. color_eyre's trait has more methods on errors, like section, warning, suggestion, context, etc. See docs
4. There are many flavors of eyre, see eyre docs
5. eyre is a progression of anyhow

Let me know what you think

[Antosser]

What do you think, @EstebanBorai ?

[Antosser]

@EstebanBorai
Runtime errors are not really likely to happen. There still are a lot of unwraps, I couldn't understand the codebase well enough to fix them all, even though it probably is possible. There is still a long way to go.

Using color_eyre would not improve the user experience in the current state by a lot, simply because there are still so many unhandled unwraps. However, color_eyre makes the errors that are handled - most of them during the initialization - much prettier. Not only can you add context to the errors, you can also add suggestions, sections in the error, and warnings. Errors, like you saw in #426, would not have been possible with anyhow

Unwrapping is not a way to handle errors

[EstebanBorai]

@EstebanBorai

Runtime errors are not really likely to happen. There still are a lot of unwraps, I couldn't understand the codebase well enough to fix them all, even though it probably is possible. There is still a long way to go.

Using color_eyre would not improve the user experience in the current state by a lot, simply because there are still so many unhandled unwraps. However, color_eyre makes the errors that are handled - most of them during the initialization - much prettier. Not only can you add context to the errors, you can also add suggestions, sections in the error, and warnings. Errors, like you saw in #426, would not have been possible with anyhow

I think we could easily achieve this, reducing binary size and build time. By:

1. Bubbling up errors
2. Handling and printing message

Not every error is a fatal error that needs a nice message printed to user's stdout.

So what do you think about first classifying them? Im in a medium/big task where Im updating every crate and then I plan to revisit error handling.

[Antosser]

IMO, fatal errors should not be possible during the server runtime. Ideally, every error should be handled by sending it to the end user or, if that's not possible, printing it out in an non-fatal way. This is currently done by unwrapping because they happen on a separate thread and don't cause any damage.

Initialization errors are pretty much always fatal and must be handled as such. Manually printing out the error and terminating the program is not a good idea since it disrupts the flow of the program, i.e., it's not rusty and it's not good error handling.
Initialization errors should always be returned from the functions where they occur.

What did you mean by Bubbling up errors?

[EstebanBorai]

IMO, fatal errors should not be possible during the server runtime. Ideally, every error should be handled by sending it to the end user or, if that's not possible, printing it out in an non-fatal way. This is currently done by unwrapping because they happen on a separate thread and don't cause any damage.

I agree with always handling, it is of course the right thing to do.

But there might be cases where application design, make certain assumptions that are not compatible
with user's expectations.

If this happens theres not much a user could do, other than report the error and provide a design
to address such issue.

Initialization errors are pretty much always fatal and must be handled as such. Manually printing out the error and terminating the program is not a good idea since it disrupts the flow of the program, i.e., it's not rusty and it's not good error handling.
Initialization errors should always be returned from the functions where they occur.

This HTTP Server has 2 main phases:

1. Initialization
   a. File or Argument parsing into Config
   b. Loading Config into Server startup
2. Server Execution
   a. Based on the provided config, the server initializes services and run them

The only place a user could have access to address issues is Phase 1, Phase 2 is where our
assumptions live. So theres actually profit on error reporting for a small portion of the
codebase. Other than that, errors are in a phase where the user has no longer access.

Lets pretend the following scenario, our http-server counts with a --max-body-size argument
which limits how many bytes the HTTP Request/Response Body can hold.

During server execution the user cannot change (as of today) the maximum allowed body size, but
turns out the server receives a Request Body which bytes exceeds the maximum allowed by config.

Here we could use Error Handling, by acknowledging the issue and perhaps take action, in any case
we want to report the user such problem, but that can be easily done by appending to the logs.

In this scenario, error reporting like color-eyre is not helpful, in this case you dont want to
terminate program, nor write to stdout in a different format.

[EstebanBorai]

For Initialization a plain message is enough because you are likely to abort on the firt parsing error or invalid configuration error.

In the other hand, on server execution, logging is enough, because we can rely on it not only for
auditioning but also for error reporting.

I would classify errors in the service/addon layer using thiserror, then make sure each addon returns a well-known error that can be either:

• Handled in runtime
• Reported as part of logs