> > The litmus test for panic! vs. Result<T,E> is not rarity of occurrence, it's whether the condition represents a programming bug or a recoverable error. > Be

> > The litmus test for panic! vs. Result<T,E> is not rarity of occurrence, it's whether the condition represents a programming bug or a recoverable error. > Because that exact same conceptual separation worked so well for Java with checked vs unchecked exceptions... > Everyone just started using unchecked exceptions because they provide an easier coding experience. Indeed. That's a problem with exceptions and checked exceptions and the choices in Java around that, not the idea that operational and programming errors might be handled differently. > Also, there's legitimate situations where the library cannot make that decision, but rather the user. What you're describing is that different components may choose to treat these separately. That's fine -- there doesn't need to be an objective answer. You can have one library say "allocating too much memory is not an error we care to deal with and we treat that as a programmer error". And people using that can be told that's a limitation. That's fine. All components have limitations. Another library that implements the same thing can say "we treat allocating too much memory as a recoverable operational error and express it in this way". It's all tradeoffs. That also doesn't mean _all_ such cases are subjective. Another comment mentioned an index out of bounds in quicksort. That's completely within the control of the implementation and in most contexts there's no reason that should ever be a recoverable error.