Global Error Handling

[DartBot]

This issue was originally filed by [email protected]

---

Feature request: add global error handling functionality to Dart similar to JavaScript's window "onerror" event: https://developer.mozilla.org/en-US/docs/DOM/window.onerror

Discussed in Dart-Lang group: https://groups.google.com/a/dartlang.org/forum/?fromgroups=#!topic/misc/11zYWSbDCNU

The best solution/workaround that was given in the discussion group was to wrap main() in a try/catch but that doesn't catch any errors in event listeners or async calls.

[dgrove]

Added Area-HTML, Triaged labels.

[munificent]

This isn't just an HTML thing. We'd like this available even on the standalone VM so that, for example, unittest could handle assertion failures outside of async wrappers.

[DartBot]

This comment was originally written by [email protected]

---

One possible approach is letting the isolate die and catch the error in another isolate (i.e., isolate monitoring, which is issue #2035).

[dgrove]

cc @justinfagnani.
cc @madsager.
cc @blois.
Removed Area-HTML label.

[DartBot]

This comment was originally written by [email protected]

---

Is the approach of letting an isolate die and then catching the error in another isolate something that I can implement now and have operational using the dart2js converter program?

[blois]

I agree that this should exist in the VM as well and have the same method signature for both.

I believe that this is a fairly important component for creating reliable applications.

[justinfagnani]

Isolate cannot yet catch death signals from another isolate, but even so I don't think that's sufficient since the main isolate would still need a global error handler, unless the main isolate could die and have a child take over.

I think a global error handler setter in dart:isolate could work well here.

[anders-sandholm]

Something nice is in the making.
Florian+team should be able to give an update later.

---

cc @floitschG.
Added Area-Library label.

[floitschG]

We will take that one for now.
If the VM, html or dart2js team has suggestions or wants to move forward without waiting for us, don't hesitate to contact us or take it over.

---

Set owner to @floitschG.
Added Accepted label.

[justinfagnani]

Florian, I filed 6945 for onExit and onSignal handlers, which is similar or could be viewed as duplicate. What I'd really like to see here is some wat in dart:isolate to get metadata about the current isolate. That object could have onError and onExit setters.

[DartBot]

This comment was originally written by [email protected]

---

Really looking forward to this, as we move real close to using our Dart app in a business-critical production environment. Any updates? Thank you for the great work!

[floitschG]

Marked this as being blocked by #9273.

[floitschG]

Marked this as being blocked by #9274.

[lrhn]

Added Library-Isolate label.

[floitschG]

Set owner to @lrhn.

[lrhn]

The solution is to run the code in a Zone with an error handler. This will catch all uncaught errors.
An alternative is to run the code in another isolate, and listen on the uncaught errors of that isolate (when implemented).

We could add the ability to listen on the current isolate, but giving access to the current isolate in a global way is dangerous (pausing yourself, or other similar stuff), so it's something I'd prefer only doing if there is a problem that using a Zone can't fix.

So, closing as not-planned for the global error handler, with an option to add Isolate.current (with it's addErrorListener) in case we find something that zones can't handle.

---

Added NotPlanned label.