Here is a common workflow in Java for debugging a unit test that unexpectedly throws an exception (which is later caught):

1. Set a breakpoint at the top of the broken unit test.
2. Launch unit tests.
3. When the breakpoint is hit, instruct the debugger to break on all exceptions.
4. Continue executing the test.
5. The debugger stops at the point where the undesired exception is thrown.

This workflow doesn't work in the Dart editor, because the user preference for "break on exceptions" only takes effect when the program is launched. This means that the user can't wait until step 3 to instruct the debugger to break on all exceptions--they have to do this before launching the unit tests. As a result, there is no way to avoid wading through all of the exceptions thrown during execution of non-broken unit tests. In a project with hundreds or thousands of unit tests this is impractical.

See also issue #13414.