This comment was originally written by Erik.G...@gmail.com

Step 1 should be "Set the editor preference Run and Debug -> Break On Exceptions to 'Uncaught'"

Added Area-Editor, Triaged labels.

Set owner to @devoncarew.
Added this to the Later milestone.
Removed Priority-Unassigned label.
Added Priority-Medium label.

This comment was originally written by @zoechi

The DataCloneError is issue #14779

I think what's happening here is that the Zone is catching and handling the error. From the POV of the application and the user it's an uncaught exception. From the POV of the debugger it's been caught and handled. We need to reconcile the two viewpoints.

Adding Florian (who I think did the zones work) and Matthias to get their thoughts.

cc @floitschG.
cc @mhausner.

Yes.
We need to breakpoint into handleUncaughtError of the rootZone to give users a good experience. There is not a lot we can do to avoid that.

Fwiw browsers have a similar issue with onerror. They consider errors as uncaught, even if the onerror handler returns true.

This comment was originally written by @mhausner

It looks like either we bake the knowledge as to what counts as an uncaught exception into the core VM, or we leave it up to the debugger front-end to determine whether an exception should be considered as uncaught or not.

The debugger client can implement this by telling the VM to break on all exceptions, and then determine which ones to show to the user and which ones not.

Fwiw there could be some interesting logic involved.

For example:
===
var f = new Future.value(499);
f = f.then((x) => throw "bad");
f = f.then(print);
===

Here the throw "bad" is uncaught. The problem is, that we only know that once we have run through the successors (here the "print").
A great debugger could have enough knowledge to see that the 'throw' isn't handled and break already then. (This would give access to the live stack frames).

I'm bringing this up, because I expect this to have some (even if small) influence on the decision where we want to put the logic.

Removed this from the Later milestone.
Added this to the 1.4 milestone.

Removed this from the 1.4 milestone.
Added this to the 1.5 milestone.

Issue #16387 has been merged into this issue.

Removed this from the 1.5 milestone.
Added this to the 1.6 milestone.

Removed this from the 1.6 milestone.
Added Oldschool-Milestone-1.6 label.

Removed Oldschool-Milestone-1.6 label.

Added Editor-Debugging label.

cc @scheglov.

How can the debugger client know if there is any chained catchError() invocation somewhere in the other library that calls some function? Or that its test() function will actually allow to handle it?

It seems that it would require to do much Dart code analysis, which mean that it naturally belongs to VM, not to the debugger client.

import 'dart:async';

main() {
  useFuture()
  .catchError((e) {
    print('handled: $e');
  })
  ;
}

Future useFuture() {
  var f = new Future.value(499);
  f = f.then((x) => throw "bad");
  return f = f.then(print);
}

cc @devoncarew.
Removed the owner.
Removed Area-Editor label.
Added Area-VM label.
Changed the title to: "VM should pause on the throwing exceptions in futures, which will not be handled by any catchError()".

I only see the following (imperfect) solution:
when there is a completeError (or similar operation that leads to a Future with an error) the debugger breaks, inspects the completing future, and transitively looks if it has listeners. Looking for visitors is a private operation that depends on the implementation of Futures. It must be tuned for our internal implementation(s).

Note: even then it is very imperfect, since users can add error-handlers after a call to completeError.
In fact: new Future.error(499) by construction doesn't have an error-handler yet. I have no idea how to handle this case... :(