Allow runtime syntax errors to be caught

[nex3]

Currently the following code throws an uncatchable syntax error:

import 'dart:async';

void badFn() {continue;}

void main() {
  runZoned(() => badFn(), onError: (error, stackTrace) {
    print("caught error");
  });
}

This doesn't print "caught error", but instead kills the isolate due to the error. However, the error is only thrown at runtime, as can be seen with this modification:

void badFn() {continue;}

void main(List<String> args) {
  if (args.isNotEmpty) badFn();
}

This only throws a syntax error if an argument is passed on the command line. Moreover, the error is recoverable; for example:

// inner.dart
import 'dart:async';

void badFn() {continue;}

void main(List<String> args) {
  new Future(() => badFn());
  badFn();
}

// outer.dart
import 'dart:isolate';

main() async {
  var isolate = await Isolate.spawnUri(
      Uri.parse("inner.dart"), [], null, paused: true);
  isolate.setErrorsFatal(false);

  var receivePort = new ReceivePort();
  isolate.addErrorListener(receivePort.sendPort);
  isolate.resume(isolate.pauseCapability);

  receivePort.listen((error) => print(error.first));
}

Running outer.dart will produce two errors, so clearly there's a way to keep the isolate running and even keep badFn callable despite this syntax error.

---

This is important for use cases like the test runner, where user code is loaded and specific functions are run. Error reporting should be associated with the functions that cause the errors, but they can only be captured globally and there's no way to link them back to the actual function that failed.

This also means that the user can't be confident that running an arbitrary function in an error zone will capture any errors that function might produce. This is useful even when not loading code dynamically; for example, an application may want to have a global error handler for itself that shows an error-reporting dialog.

[kevmoo]

@sgjesse @lrhn Thoughts on this? Straight-forward?

[lrhn]

@iposva-google

It's the VM that decides what to do with a syntax error. I believe it currently makes it a top-level error and drops the current stack - it doesn't throw an error as such.

Setting errors non-fatal and listening on isolate errors does work to see the errors, but it doesn't mean that recovery is possible. It's also problematic to drop the stack without executing finally blocks. That wasn't a problem before errors could be made non-fatal, but now it's visible.

Example:

// inner.dart
import 'dart:async';
import 'dart:isolate';

void badFn() {continue;}

void main() {
  Isolate.current.setErrorsFatal(false);
  RawReceivePort p = new RawReceivePort(print);
  Isolate.current.addErrorListener(p.sendPort);
  Timer.run(() {  // Wait for the isolate calls to be handled.
    new Future(() => badFn());
    try {
      print("1");  // Printed
      badFn();
    } finally {
      print("2");  // Not printed!
    }
  });
}

In general it's not nice to have a try/finally execute the try and not the finally when the isolate stays alive. It may cause logical problems if a mutex is entered but not released, or similar problems.

That also makes me expect that the first syntax error will rewind right through the microtask queue code and stop executing microtasks until the next event loop event. An uncaught error in a microtask will reach the event loop, but a finally block on the way reschedules the microtask loop if there are more pending microtasks. If finally blocks are ignored, that fails too.

It may be a prettier solution to throw a SyntaxError from the call-point, just as we do for other "warn-at-compile/fail-at-runtime" errors, but that's a design decision for the VM people. The spec is silent on how a syntax error must be reported.

[munificent]

cc @asadovsky

[mhausner]

Reporting syntax errors in code that isn't executed is contrary to what the goals for Dart have been since the beginning. The stated goal was to be as forgiving as possible when running code, so that fast edit-execute cycles support rapid prototyping. The language spec reflects that, by making many errors only fire at runtime, rather than at compile time, even if they are detected by the compiler.

[kevmoo]

"fire at runtime" is totally fine – we just want at way to know that an isolate failed BECAUSE of bad syntax with the related info.