Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors in async blocks are propagated too slowly #23497

Closed
nex3 opened this issue May 20, 2015 · 4 comments
Closed

Errors in async blocks are propagated too slowly #23497

nex3 opened this issue May 20, 2015 · 4 comments
Assignees
Labels
area-vm Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends.

Comments

@nex3
Copy link
Member

nex3 commented May 20, 2015

If an error is thrown in an async block, it propagates to the zone's error handler much more slowly than one thrown in a non-async context. For example:

    import 'dart:async';

    void main() {
      runZoned(() async {
        scheduleMicrotask(() => throw 'in microtask');
        throw 'in async function';
      }, onError: (error, stackTrace) {
        print("caught $error");
      });
    }

this prints:

    in microtask
    in async function

which is not expected, since "in async function" is thrown before "in microtask". Compare to the version without async:

    import 'dart:async';

    void main() {
      runZoned(() {
        scheduleMicrotask(() => throw 'in microtask');
        throw 'in async function';
      }, onError: (error, stackTrace) {
        print("caught $error");
      });
    }

and the version that runs the entire body in a microtask:

    import 'dart:async';

    void main() {
      runZoned(() {
        scheduleMicrotask(() {
          scheduleMicrotask(() => throw 'in microtask');
          throw 'in async function';
        });
      }, onError: (error, stackTrace) {
        print("caught $error");
      });
    }

both of which print

    in async function
    in microtask

as expected.

This is very important for testing (among other things), where errors have to be handled specially and users have strong expectations for their consistent ordering.

@iposva-google
Copy link
Contributor

Removed Priority-High label.
Added Priority-Unassigned label.

@floitschG
Copy link
Contributor

This might be trivial to fix, by switching to sync-completers.
I'm too tired to think too deeply about it, and it will need more people thinking this through, but at the moment I think that should do it.

For dart2js the patch would be (assuming that the completer-constructor lookup is only used for the async-rewrite):

diff --git a/pkg/compiler/lib/src/js_backend/backend.dart b/pkg/compiler/lib/src/js_backend/backend.dart
index 986a313..f3067d1 100644

--- a/pkg/compiler/lib/src/js_backend/backend.dart
+++ b/pkg/compiler/lib/src/js_backend/backend.dart
@@ -1852,7 +1852,7 @­@ class JavaScriptBackend extends Backend {
   Element getCompleterConstructor() {
     ClassElement classElement = find(compiler.asyncLibrary, "Completer");
     classElement.ensureResolved(compiler);

  • return classElement.lookupConstructor("");
  • return classElement.lookupConstructor("sync");
       }
     
       Element getASyncStarController() {

cc @lrhn.
cc @sigurdm.

@nex3 nex3 added Type-Defect area-vm Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends. labels May 29, 2015
@floitschG floitschG self-assigned this Aug 11, 2015
@floitschG
Copy link
Contributor

Fixed in f2d0814.

@kevmoo
Copy link
Member

kevmoo commented Oct 14, 2015

Thanks, @floitschG !!!

nex3 added a commit to dart-lang/test that referenced this issue Feb 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-vm Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends.
Projects
None yet
Development

No branches or pull requests

4 participants