DDC doesn't offer a way to log formatted errors/traces

[matanlurey]

This issue is blocking resolution of angulardart/angular#1367.

Almost everything can be viewed at angulardart/angular#1367, but basically:

• throw should log a nice JavaScript error and stack trace by default.
• Logging an exception/stack trace manually (AngularDart does this) should be formatted.

For example, I'd like the output in the browser to look like this when we are done:

(Obviously not minified, this is just an example from Dart2JS that works fine)

Instead of this:

[matanlurey]

As mentioned by @vsmenon - this is fixed if I enable "Custom Formatters" in devtools:

http://www.mattzeunert.com/2016/02/19/custom-chrome-devtools-object-formatters.html

[matanlurey]

Actually will reopen because I'm confused how Dart2JS does this for free.

[matanlurey]

Ping. Is this a bug? Intentional? Something else?

[vsmenon]

@jmesserly

It's not exactly free. Dart2JS is wrapping all throws in a JS Error object and unwrapping on a catch. Chrome dev tools (but not node) formats the native Error in a specific way.

DDC could do similar, though it would increase code size on throw / catch.

[matanlurey]

Do we know what the cost is?

Seems a bit suspect that it is OK for production but not the dev compiler.

[jmesserly]

It's a question of JS interop spec: when a Dart object is thrown, what should JS see (and vice versa)? Do we wrap all thrown Dart objects in a JS Error, or only some of them (e.g. only things that extend or implement dart:core Error/Exception)?

The DDC/Dart 2 approach is to use wrapperless interop when possible. There are many benefits to that in general.

I think we hit a problem here because most Dart Error/Exception types do not correspond to JS Error. I think there may be a mismatch in stack traces between JS and Dart, which is why we kept them distinct (I think JS Errors capture stack at creation, rather than when thrown).

Considering all of that, the simplest approach is probably to wrap all throws. I don't think it will be a noticeable perf issue because IIRC, we already create JS Error objects anyways for stack traces.

[matanlurey]

Thanks @jmesserly!

It's a question of JS interop spec:

Which I'd also love ;)

when a Dart object is thrown, what should JS see (and vice versa)? Do we wrap all thrown Dart objects in a JS Error, or only some of them (e.g. only things that extend or implement dart:core Error/Exception)?

Hard to answer that question definitively. Here are some questions:

• How useful is it to throw something that doesn't implement Error or Exception
• If we support other arbitrary objects, do users expect those to be valid JS errors

My guess is making all Dart errors JS errors feels "right", and where/when it isn't possible, we can just not do it. Personally this is part of the language that doesn't make a lot of sense to me - I can sort of see throw <string> as useful if its just sugar for throw new Error(string), similar to the callable classes de-sugaring.

The DDC/Dart 2 approach is to use wrapperless interop when possible. There are many benefits to that in general.

Could you explain in 1 or 2 sentences what that is and why that benefits users?

I think we hit a problem here because most Dart Error/Exception types do not correspond to JS Error.
I think there may be a mismatch in stack traces between JS and Dart, which is why we kept them distinct (I think JS Errors capture stack at creation, rather than when thrown).

Considering all of that, the simplest approach is probably to wrap all throws. I don't think it will be a noticeable perf issue because IIRC, we already create JS Error objects anyways for stack traces.

My read of this is you agree that Dart2JS and DDC should have similar semantics here?

[jmesserly]

The DDC/Dart 2 approach is to use wrapperless interop when possible. There are many benefits to that in general.

Could you explain in 1 or 2 sentences what that is and why that benefits users?

Generally: wrapperless interop performs better, allows passing complex structures (e.g. objects of user-defined classes), provides identity semantics, allows incremental porting and/or hybrid apps (because each language can express all of the necessary operations on the same shared data structures). It also makes writing the interop API signatures easier.

My read of this is you agree that Dart2JS and DDC should have similar semantics here?

Yes.

[matanlurey]

Thanks!

[matanlurey]

This fell off a bit, /cc @vsmenon for now. How can we act on this?

[vsmenon]

We should be encouraging folks to enable custom formatters immediately (per https://webdev.dartlang.org/guides/debugging).

Flagging for @jmesserly to update when she's back. I suspect we'll want to do this in conjunction with #34060.

[matanlurey]

Any more action here?

[jmesserly]

Any more action here?

Sort of :). I started taking a look at this yesterday as I was reviewing bugs. Will update when I have a CL ready.

[matanlurey]

Thanks! Just doing a bug scrub - there is an usptream google3 bug blocked on this one.

[jmesserly]

I'm juggling a lot of things right now :), but I did manage to finally upload my fix for this: https://dart-review.googlesource.com/c/sdk/+/84446

[zolotyh]

Hi, I have a problem with the formatting of stack traces. I am using stagehand (stagehand web-simple) for creating a simple project and webdev serve for running it. I have unformatted traces.

example code:

void main(){
    throw '123123123';
 }

What I am doing worng? FYI @matanlurey

[matanlurey]

Ping @jmesserly 😛

[jmesserly]

I landed a CL that changes DDC to throw JS errors--they'll be better understood by JS tools, etc.

Tracking of the Dart StackTrace object is improved for async and async* functions (there were some circumstances where the original trace could get dropped).

That sounds like it'll address your original issue, but I'm not 100% sure (were there other things you wanted?)

[jmesserly]

Added "needs-info" ... LMK if there's anything else you need (or, should we open another issue for additional requests?)

[matanlurey]

I landed a CL that changes DDC to throw JS errors--they'll be better understood by JS tools, etc.

Thanks! Is that expected to make it into google3 anytime soon? If so, we can close this!

[jmesserly]

SGTM! thank you

[jmesserly]

edit: yeah it'll make it in the next roll; or it may have already happened (I'm not sure what the holiday schedule was). But in any case, yeah, soon.

[jmesserly]

sadly need to revert this for now, there are some (very obscure) failures in a few tests.

I wasn't able to make too much sense of it, but it looks like code may be relying on DDC's former, incorrect behavior. When async code loses a stack trace, and passes in explicit "null" where a trace is expected, we used to keep the old stacktrace (the thrown object stored it). That's not technically correct behavior in DDC, but it's useful.

Perhaps I can back out of some parts of the CL, while keeping the "always throw JSError" part. Needs more investigation.

[matanlurey]

😢

I wasn't able to make too much sense of it, but it looks like code may be relying on DDC's former, incorrect behavior.

What code? Clients in google3? The SDK itself?

If its the latter, I don't mind helping to debug.

[jmesserly]

It wasn't clear who was passing in the null, it was an async error so the origin got lost :\ ... and any breakpoints or "break on exception" was making the bug go away. It could be some code in DDC's SDK impl, I'm going through that to see if anything jumps out. Also I'm trying some "shot in the dart" type of fixes.

(That might not even be the root cause, but it is odd. A future then handler should never be passed "null" as the stack trace.)

[jmesserly]

wow, spoke too soon, turns out my "shot in the dark" may have worked. Either the "preserve stacktrace when null is passed" or the "preserve original stack trace, even when throw is used" fixed that test.

[jmesserly]

https://dart-review.googlesource.com/c/sdk/+/89060