Synchronous errors in runZoned should be passed to handleUncaughtErrors

[nex3]

Consider the following code:

    main() {
      runZoned(() {
        throw 'error 1';
      }, onError: (error, stack) {
        print("Caught $error");
      });

      runZoned(() {
        throw 'error 2';
      }, zoneSpecification: new ZoneSpecification(
          handleUncaughtError: (self, parent, zone, error, stackTrace) {
        print("Caught $error");
      }));
    }

The first [runZoned] prints "Caught error 1", as expected. The second, however, top-levels the error. I'd expect it to behave like [onError] and pass synchronous errors to [handleUncaughtError].

[lrhn]

There is a distinction between Zone.run and Zone.runGuarded. What you are seeing here is that distinction.
The onError parameter makes the body be run with runGuarded, and without that parameter, it just used run.

The documentation could be better.

[lrhn]

That said, it is confusing that we have both run and runGuarded. We say that an error can't leave an error zone, which is a zone with an error handler, so why can a sync error leave a Zone.run?

[floitschG]

We should say that an asynchronous error can't leave an error zone.

There are use-cases where the caller can deal with synchronous errors and doesn't want to go through a callback.

[nex3]

Consider this a request to use Zone.runGuarded rather than Zone.run in runZoned even if no onError handler is passed, then.

[lrhn]

We don't want to change runZoned to use runGuarded.
The runZoned call is a simple and primitive way to run code in a different zone, and if that zone doesn't have a different error handler, there is no need to intercept errors.

I wouldn't mind using runGuarded if an error handler is provided, but it would be a change of behavior.

[lrhn]

Changing behavior of runZoned now is not worth the risk of breaking existing code.

We can at most add a runZonedGuarded function with a different behavior.

---

Added NotPlanned label.