cc @abarth

Assuming the approach is sound, I'll add tests to https://github.com/flutter/engine/tree/master/testing/dart

I would check whether throwing a dart exception in C++ unwinds the C++ stack (i.e., if it calls C++ destructors as it pops the stack). I've been scared to use them because I wasn't sure if it skipped the destructors.

Dart_ThrowException does not run C++ destructors for any objects on the stack. It jumps directly into another context (similar to setjmp/longjmp).

Is there any way to prevent developers from extending native wrapper classes? Dart doesn't seem to have a notion of final classes.

Ah, yes, a closer look at the code that does the clean up when throwing exceptions seems to suggest that it's actually only releasing Dart stack resources, not C++ ones (looking at StackResource::UnwindAbove). That's unfortunate.

I'll audit all the places I'm using this to make sure you can't get to them after allocating or initialising anything, then add comments to this effect.

Is there any way to prevent developers from extending native wrapper classes? Dart doesn't seem to have a notion of final classes.

Extending is mostly fine, the real problem is that in release mode you can pass anything you want, there's no type-checking, and even when there's type-checking you can't guarantee that a class that implements, say, Canvas, is actually a class that inherits from the real Canvas.

So the problems are where I used ThrowAndLogIfError. As best I can tell, all the cases where I did that are cases where actually an assert is more appropriate because you can only get there via private paths in the dart:ui library, so I've reverted those to FTL_DCHECKs.

I think that addresses the concern above.

I'll add some tests then post a new patch.

Added a test, which crashes on trunk but passes with this patch.

Since this no longer depends on the tonic changes, I'll check it in on green unless I hear otherwise.