> It is quite a hard thing to predict which errors will be handled and which will not at the point that you create an error :)
Not really, no? To first approximation all errors are system call failures: file not found, OS couldn't hand you enough memory so you got a heap allocation failure, network timeout, etc... You know exactly where those can happen because they are exposed as functions with some kind of error code specified as part of the return value.
There are situations where that's not true, but those situations tend to be fairly rare: things like "schema" violations in some backend data store ("product has a null manufacturer field", which should never happen but it turns out it does for data imported via that merger 2 years ago). And these tend to have correspondingly complicated handling ("add it to the queue of manual fixup requests") not well captured by "print a stack trace and crash".
Again, demanding the need to know what is happening "higher up the stack" to understand an error is a symptom that the error is UNhandled. Handling it means understanding those things, generally by inspecting the return code in the higher caller where the context is understood.
And you're absolutely right, if you don't handle errors than a stack trace is a great way to reverse engineer the context. But that's not "handling" the error, it's debugging. And those are different tasks.
I genuinely don't understand how you get from the sentence "You want a stack when you have an unhandled error and need to figure out what went wrong." to "You are saying we don't need stack traces". All I can suggest is that you re-read the thread more carefully.
Not really, no? To first approximation all errors are system call failures: file not found, OS couldn't hand you enough memory so you got a heap allocation failure, network timeout, etc... You know exactly where those can happen because they are exposed as functions with some kind of error code specified as part of the return value.
There are situations where that's not true, but those situations tend to be fairly rare: things like "schema" violations in some backend data store ("product has a null manufacturer field", which should never happen but it turns out it does for data imported via that merger 2 years ago). And these tend to have correspondingly complicated handling ("add it to the queue of manual fixup requests") not well captured by "print a stack trace and crash".