[austin-cheney]

You made the same mistake as the grandparent by assuming I/O means something more specific than it does. At any rate there isn't a good reason to bubble error objects out of the event handler and secondly even if you did you would have everything you need to fully describe the problem within the error object including the stack trace, event type, error message, and so forth.

Its an equivalent breeze in JavaScript as well unless you are fumbling through abstraction layers (frameworks) that eliminate the information you need.

[thrashh]

Not at all. You don't have to describe anything when throwing an error because that's the point of exception inheritance. Second, the whole point of exceptions is to bubble them out of the handler(!) because otherwise you would use return values (like in Go).

Since you are saying that you have to describe the problem within the error object, it sounds like you must be you are parsing error messages and stack traces to figure out what the error is. That's not how exceptions are to be used and I think that's why you are not seeing why you would bubble errors.

In other languages, you don't have to do any of that nonsense because object identity is much stronger, but JavaScript uses prototypical inheritance so you can't really tell if an error is an ImageError or an IOError. Despite this issue, exceptions were added to the JavaScript language without resolving that problem. The reason why you have to worry about frameworks eliminating error information is because that problem wasn't resolved and so frameworks roll their own error handling and there is no standard.