3 ms·

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 :) So I disagree. This is a pedantica

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 :) So I disagree. This is a pedantically narrow view of what "error handling" is. Printing a stack trace and crashing is also "handling" it.

ajross 3y ago
> 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".
- hamandcheese 3y ago
  > Not really, no? To first approximation all errors are system call failures How does this help predict whether they are handled or not higher up the stack?
  - ajross 3y ago
    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.
    - hamandcheese 3y ago
      So to be clear, are you saying we don't need stack traces because we should handle 100% of errors instead?
      - ajross 3y ago
        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.

ajross 3y ago

> 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".

hamandcheese 3y ago
> Not really, no? To first approximation all errors are system call failures How does this help predict whether they are handled or not higher up the stack?
- ajross 3y ago
  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.
  - hamandcheese 3y ago
    So to be clear, are you saying we don't need stack traces because we should handle 100% of errors instead?
    - ajross 3y ago
      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.