Closed edude03 closed 1 year ago
Thank you for the PR, and sorry for only reacting so late!
I think at this time, it makes more sense to migrate to anyhow
instead of thiserror
, so I am closing this.
Hey no worries.
I disagree though that anyhow should be the goal of the migration - ideally you want both, a way to specify exactly what error happened (error chain, thiserror) and a way to communicate an error happened to the user (anyhow, eyre).
So personally I'd still do the migration to thiserror and then another round of work to add eyre
I agree in principle, but I feel that for a project of the size of nix-index, having a separate error type is overkill. There is not much benefit in splitting the "communicate the error to the user" and "generate a structured error type" here.
I know that generating error messages directly at the point where the error happens feels unclean. But it has the big advantage that we can generate customized messages with all the info that is present at that point, without having to first collect all the info into an error type and write a separate display method.
Part 2 of my quest to solve #152, update the error library.