alt Hacker NewsIf your error domain has only one useful category why not just create an error type with a useful message and be done with it. Why use anyhow at all? You are essentially saying the error domain is small so the work is tiny anyway.
anyhow seems useful in the very top layers where you basically just want bubble the useful errors modeled elsewhere to a top layer that can appropriately handle them. I don't think a crate should abdicate from modeling the error domain any more than they should abdicate from modeling the other types.
Replies
>I don't think a crate should abdicate from modeling the error domain any more than they should abdicate from modeling the other types.
Yes, it's just harder. We usually have a pretty good idea what callers want from the happy path, but the range of things that callers may or may not want to do in case of an error is very broad.
I'm trying to describe a rather large spectrum of situations, and how most of them are favorable (or not unfavorable) to anyhow.
I'm not saying the error domain is small per se.
Instead, one argument I'm making: what you're describing about errors bubbling up to the top layer, is what happens with the overwhelming majority of errors in my experience.
Whether the error space is large or small, just wait until you have an immediate need to treat one error different from the rest. It happens, it's just not common.
I didn't steelman the case for when to use enums, but in short: In a tiny error space or as valuable documentation.
(The doc value is undermined somewhat when projects use 1-big-error and functions that eg only returns 3 of the 6 possible errors)
I'm not advocating removing an Error enum. Just that writing one can and should be postponed, saving a lot of maintenance edits.