Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper error handling #6

Open
strohel opened this issue Dec 18, 2023 · 3 comments
Open

Proper error handling #6

strohel opened this issue Dec 18, 2023 · 3 comments
Assignees

Comments

@strohel
Copy link
Member

strohel commented Dec 18, 2023

Currently we do just .expect(), which doesn't scale.

Do people (@mbernat?) have opinions on "dynamic" errors (anyhow) vs. more statically defined (thiserror)?

If we target being a library, then static thiserror-like errors are more appropriate, but I wonder if that isn't an overkill doing now in the prototyping phase. (we should start with anyhow and eventually convert to thiserror).

And meybe there's some alternative to the 2 mentioned libraries?

@PabloMansanet
Copy link

Personally, for this prototyping phase I'm OK with anyhow. As an alternative we could use eyre, which I haven't used for any personal project yet but I hear is pretty good (I kinda remember one of you using it for something, but I'm not sure)

@mbernat
Copy link
Collaborator

mbernat commented Dec 18, 2023

I don't think the two approaches are exclusive, thiserror to define good errors where they make sense and anyhow / eyre for error reporting.

Even for a prototype it would be nice to have a little bit of library code, I'm not super fond of having everything in main.rs.

@goodhoko
Copy link
Member

@PabloMansanet we were using eyre in my evaluation project 😉 The advantage over anyhow is probably the nicely colored output. .)

@goodhoko goodhoko self-assigned this Dec 20, 2023
@mbernat mbernat mentioned this issue Dec 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants