Error handling

[MartinKavik]

This is a "tracking issue" for error handling to discuss and find a best way for error handling in Seed and Seed apps.

Interesting links:

• Rust: Structuring and handling errors in 2020
• https://github.com/rust-lang/project-error-handling

Libs:

• anyhow
• thiserror
• eyre
• snafu
• failure (deprecated)

[flosse]

• failure

you might add a note that failure is deprecated ;-)

[MartinKavik]

Thanks! Updated and I've added some other libraries that was recommended as failure alternative.

[ghost]

+1 for thiserror or standard Rust implementation as they amount to the same thing and do not require any external libraries when Seed is being used as a library.

Things like failure seems to stop development of a lot of projects because needing to re-write to remove it was an excessive amount of work. Even if thiserror becomes deprecated (or if Rust implements something similar directly into the language) nothing has to be changed code-wide.

[lunaryone]

+1 for thiserror

anyhow designed to be used in applications(not libraries)
eyre is fork of anyhow
snafu is pretty similar to thiserror

As for me it just dilemma between snafu and thiserror.
Thiserror more popular (according to crates.io statistics)
And I'm absolutely agree with @asvln

Changes for seed with thiserror support is pretty simple. The biggest problem in the is create understandable error messages for websys errors

[flosse]

+1 for thiserror or snafu

[lunaryone]

Probably this link would be useful: https://github.com/rust-lang/project-error-handling

[mankinskin]

On a top-level, I can think of two different kinds of errors:

• errors that should be notified to the user i.e. should be reflected by the UI
• errors that should be recovered from internally i.e. should not notify the user, but possibly the server

I think to handle any of these errors we should think about Results and how they are handled in a seed app.

Currently, I always just log any Result::Errs in the update function of my components. Sometimes I also write to some variable in the model and render the error in the UI.

Another part where errors need to be handled is in the init functions. My current init functions don't return a Result, because there is no way to propagate errors anywhere and I would have to do the error "handling" in place anyways.

So the only points that need to handle errors are init and update I think, because those are the only places where state can change. Any functions called there can return Results and return errors. The question is, how these errors should then be handled in those functions.

The answer to this is probably very individual. Maybe some applications want to show a notification in the corner, maybe others want to play a sound, some may want to send a message to the server. So I guess a lot of error handling will stay in the responsibility of the library user.

[mankinskin]

What I noticed is that there are currently issues with Error handling when using messages. Messages usually have to implement Clone to use them with subscribe/notify, but Errors usually do not implement clone. Maybe a good start for error handling would be a special Error trait that can be propagated through Orders: orders.error(err);

Basically each component could implement a separate type for Errors next to the usual Message type, which does not implement Clone.

[techninja1008]

I'd like to also +1 the implementation of std::error::Error on all of seed's error types. This seems to be the idiomatic pattern for error handling within libraries, and can be done easily using one of the listed crates that provide a derive for it.

In my personal opinion, it'd be nice to do this sooner rather than later (I'm happy to submit a PR with a thiserror implementation) as it's not something that I see could create issues later, unless Error is completely removed from std, which isn't going to happen. It's currently making it a bit difficult for me to handle larger scale error handling within the application I'm developing.

Messages usually have to implement Clone

@mankinskin A useful pattern I've found to work around issues like this is to wrap in an Rc. This of course only really works when you don't need mutable access, but I'd say you've got bigger problems if you're trying to mutate your errors.

[MartinKavik]

@techninja1008

I'm happy to submit a PR with a thiserror implementation

I would be happy to merge it 🙂