3 ms·

I think that the "let it fail" approach is often inevitable, even when we try to use Result<T, E>. Often, we see an "unknown" variant in the error enum, as a c

I think that the "let it fail" approach is often inevitable, even when we try to use Result<T, E>. Often, we see an "unknown" variant in the error enum, as a catch-all for a library's unexpected errors. Then, anyone who calls them must also have an "unknown" enum. And anyone who calls them, and so on. In the end, this "unknown" variant is similar to a panic, in that there's very few reasonable reactions to it: Log it, cancel the request, return error 500, perhaps retry. For this reason, I often recommend people to just use assertions and panics.

hyperhopper 4y ago
While everything you said is correct, there are still significant advantages to the 'result' method. Sometimes you want to return 200 even if most of the backends fail. Sometimes one part may want to retry based on any error. Even aside from this, disallowing exceptions leads to a very predictable control flow, and makes program state able to be expressed in the type system, which is useful for many reasons on it's own. While yes, it's often just like an exception or panic, I'll take that over exceptions in my code any day
- verdagon 4y ago
  I realize I was ambiguous; I didn't mean to say "just use assertions and panics", I meant "just use assertions and panics for unexpected errors", my apologies. I wouldn't recommend someone only use Result<T, E> and never panic. If we do, then anything that might indirectly be invalid, such as a map lookup or an array index, will have ? operators on it, often every line of some functions. In the end, our control flow is just as unpredictable as if we just used panics and our signal is lost in the noise. For this reason, I think a blend of Result<T, E> and panics/assertions is really the way to go.