Need a global error handler primitive in the VM

[floitschG]

We need a way to set the global error-handler. For now just having a private VM specific implementation is good enough. We can then provide a public API on top of it.

[floitschG]

Marked this as blocking #5958.

[floitschG]

Also see issue #9274.

[sethladd]

Yes, please. :)

[iposva-google]

As far as I know this was blocked on feedback from the library team.

---

Set owner to @tomball.
Added Accepted label.

[tomball]

My understanding is that developers want a causal chain that looks like a stack trace, even though it may bridge several stacks. Each isolate would be displayed as a stack frame from the code that spawned it, so an unhandled exception in a set of deeply nested async calls can be traced back to the code that created it.

I suggested having each spawn operation create a stack trace and store it in the new isolate, but that was rejected as requiring too much overhead, impacting memory footprint and performance.

[sethladd]

@tom, that's correct, we'd like to be able to walk from the async exception back to the original source of the error.

[sethladd]

FWIW, this matters during development and debugging time. So, making this a checked-mode only behavior seems quite sufficient.

[iposva-google]

This bug is about a simple primitive in the VM where global errors can be dispatched to. All other developer scenarios can be built on top once this primitive is implemented.

[floitschG]

In agreement with Ivan (comment 8). This is just about a (hidden) primitive from the VM.
Things to consider, though:

• what should be the signature of the callback? Should it get two arguments, the error and the stacktrace, or should it get a combined instance (like it is currently the case for the isolate error-handler). If it is the latter we should try to work together to merge AsyncError and that class.
• we should be able to call the global error handler without throwing. That is, the async library sometimes delays throwing of errors. When it is ready to throw, it wants to invoke the global error-handler directly. That one should behave as if someone threw an error at the top-level.
  Question here is again: how to pass in the stack-trace that should be displayed if the error is unhandled by any callback.
• Do you want to allow setting several or just one error-handler. One is probably simpler and we can always wrap it to allow more than one if we want to.

In any case: getting something and iterating on it would be already a good start.

[tomball]

Revision 16186 (https://code.google.com/p/dart/source/detail?r=16186) added support for the VM calling a "_unhandledExceptionCallback(IsolateUnhandledException e)" function in the main library, if it exists. Attached is an example Ivan wrote, demonstrating its use. This can easily be changed to call something similar in the async library.

---

Attachment:
ue.dart (441 Bytes)

[tomball]

Removed the owner.

[iposva-google]

Removed Priority-Medium label.
Added Priority-Unassigned label.

[iposva-google]

Is this still a valid request? I assume the libraries have moved a long way from this, correct?

---

Set owner to @floitschG.
Added NeedsInfo label.

[floitschG]

I'm not sure, yet.
I suggest leaving it as NeedsInfo until we really know what is needed.

[floitschG]

Set owner to @lrhn.

[lrhn]

Added AssumedStale label.