3 ms·

> And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramaticall

> And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Why make a new non-standart event instead of just throwing an error and handling it with default error handler? That is poor design - because initially there was no reporting of unhandled errors at all and only later a workaround was added.

WorldMaker 9y ago
`window.onunhandledrejection` is a part of the spec, it simply took a bit for browsers to catch up to it. It's a different handler because an application may need to know the difference between a synchronous error and an asynchronous error and handle them (dramatically) different.
- codedokode 9y ago
  If there is a need to distinguish between different kind of errors then it can be done by checking error prototype (if (error instanceof AsyncError) { ... }). There was no need to introduce a new event. I think the reason is because some developers have a kind of exception-phobia and they prefer to hide errors (make developer check for them explicitly) rather than let them bubble up. I see this in other platforms too. For example, in .NET if a background thread crashes because of unhandled exception then nothing happens to the main thread, no error is reported. The developer must check for an error and of course most developers won't care about this. Another example is how error reporting is done in a browser. JS errors are never shown to the user so if a rich JS app has an error the user won't know about it, the app will just stop working or show invalid data.
  - WorldMaker 9y ago
    Browsers have a long backwards compatibility story to deal with and the interplay of synchronous errors and the synchronous error event is a part of that. Just because you don't see a need to introduce a new event doesn't mean bright minds didn't think about it.

WorldMaker 9y ago

`window.onunhandledrejection` is a part of the spec, it simply took a bit for browsers to catch up to it. It's a different handler because an application may need to know the difference between a synchronous error and an asynchronous error and handle them (dramatically) different.

codedokode 9y ago
If there is a need to distinguish between different kind of errors then it can be done by checking error prototype (if (error instanceof AsyncError) { ... }). There was no need to introduce a new event. I think the reason is because some developers have a kind of exception-phobia and they prefer to hide errors (make developer check for them explicitly) rather than let them bubble up. I see this in other platforms too. For example, in .NET if a background thread crashes because of unhandled exception then nothing happens to the main thread, no error is reported. The developer must check for an error and of course most developers won't care about this. Another example is how error reporting is done in a browser. JS errors are never shown to the user so if a rich JS app has an error the user won't know about it, the app will just stop working or show invalid data.
- WorldMaker 9y ago
  Browsers have a long backwards compatibility story to deal with and the interplay of synchronous errors and the synchronous error event is a part of that. Just because you don't see a need to introduce a new event doesn't mean bright minds didn't think about it.