Stack traces are obfuscated

[DanTup]

In Dart-Code/Dart-Code#5367 (comment) I noted the stack traces for some errors were not very useful because of minification/wasm. After discussing with @kenzieschmoll we believed this might be VS Code-specific so to try and compare I checked what I'm getting outside of DevTools.

I can't repro the same issue, however I can force the kind of error noted at Dart-Code/Dart-Code#5158 (comment) by just running:

dt serve --dtd-uri ws://localhost:1234/invalid

When using WASM, this is what I see:

It's not clear to me if this is expected or not. There are some .dart files and line numbers in the call stack, but there are also some main.dart.wasm with hex offsets and all of the function names are obfuscated.

If I do the same without WASM, the function names are all still obfuscated although the top of the stack has some extra filenames that weren't in the wasm version (for example logger_helpers.dart:34).

I'm not certain that this is wrong, but the screenshots from @elliette at Dart-Code/Dart-Code#5158 (comment) seem like they have much better information than here.

[elliette]

I'm not certain that this is wrong, but the screenshots from @elliette at Dart-Code/Dart-Code#5158 (comment) seem like they have much better information than here.

Do you also see a better stack trace underneath the one you shared? If I recall correctly, we should be seeing two stack traces. Stack trace 1 is the one that Chrome tries to do automatically, and is semi-obfuscated. Then stack trace 2 is the one that we explicitly parse and log to the console (stack trace 2 is the one I shared screenshots of).

[DanTup]

There is another error printed before it which has English error text, but the call stack is no different (it also has a different line, so I don't know if it's really the same or a second error):

There's nothing after it though:

This was tested with latest SDK and latest DevTools, just running dt serve --dtd-uri ws://localhost:1234/invalid from a terminal.

[DanTup]

btw, when just testing something else, I noticed these bad errors show up in the user-facing messages too - slightly different between wasm/js, but both bad messages.

WASM:

JS:

[elliette]

Hmm that shouldn't be the case. I'll take a look after the holidays.