Oh, yes, absolutely. (That’s actually a much better statement than my “only of interest for debugging fatal errors”–I think what I’m really trying to get at is unexpect errors should be fatal if possible.) But how can an error be unexpected if it’s part of the signature of a method? If you don’t expect a particular error condition,
panic when you see it (again as per Duffy’s advice). In my ideal world, once a software product is ready for release, errors that can be handled are, while errors representing true unforseen bugs and conditions that were (incorrectly) assumed to be impossible are “handled” by
panicking (if indeed they’re handled at all, since the whole point is that this category of errors can’t be predicted in advance).
I suppose I can think of a very few cases where generating some backtrace information and propagating it via error-types might be useful, even in release mode. One is if there’s some way to panic inside the error-handling code several levels up the call-chain; in this case you’ll lose some potentially-crucial backtrace information if the “semi-happy-path” error-recovery mechanism doesn’t propagate the trace info “just in case”. But that seems (prima facie) like a pretty limited scenario to me.