Offer stable access to stacktrace call stack

[matthew-carroll]

StackTraces are used by various logging packages to print the class name and/or method name from which a log originates. This is currently solved by ad hoc parsing of StackTrace toString() results, e.g.,

https://github.com/magillus/flutter-fimber/blob/master/fimber/lib/fimber_base.dart#L242

I suggest that StrackTrace introduce a first-class, structured representation of the stack trace instead of an implied protocol in toString().

Relying on toString() introduces the following issues:

• every developer needs to re-implement the parsing logic (which also requires a complete understanding of the variety of stack traces that might be produced)
• toString() does not imply stable return values, it could conceivably change at any time

[matanlurey]

IIRC this is what https://pub.dev/packages/stack_trace does:

// https://pub.dev/documentation/stack_trace/latest/stack_trace/Trace/Trace.from.html
var trace = Trace.from(stackTrace);

The problem with including this natively in the language (or SDK) is that you would incur a rather high fixed cost for all apps versus the package that is able to be optional (e.g. just used in say, testing, or debug builds).

[matthew-carroll]

Yeah, I learned about that package after posting this.

The reference to a high fixed cost is interesting. Can you elaborate on what that cost would be? If toString() supports a particular protocol for serializing stacktrace structure, then the language must already be doing the work to assemble it. At that point, the only remaining work would be to parse it, right? And couldn't that still be done on-demand, avoiding unnecessary processing?

The existence of that package is probably a reasonable functional solution to this ticket. However, I'm still curious about this notion of implicitly structuring toString() responses in a particular way without that fact being recognized at the API level. Imagine that the response was changed at some point, even in a very minor way. It would likely break every logger,
and every app that uses those loggers. And yet from an API perspective, any change to the toString() response would be completely legitimate given that standard contract of toString(). In fact, I think Flutter may have an internal policy to never depend on toString() responses in code, but maybe I'm misremembering that.

[matanlurey]

The reference to a high fixed cost is interesting. Can you elaborate on what that cost would be?

I am the wrong person to give that specific information, but I know for sure that ...

The language must already be doing the work to assemble it

Ah. That is is not true. Dart has multiple runtime and compile-time formats:

• JIT
• AOT
• DDC
• Dart2JS (On a variety of browsers, Chrome, Firefox, Safari, etc)

At least a few of these (the compile-to-JS variants) use the built-in VM's Stack Trace format, which differs from the "native" (Dart) VM format fairly significantly. On those platforms, there isn't any serialization of Stack Traces (at least none that Dart itself performs other than perhaps some munging/transformation to try and normalize the results to some extent). It's also possible future compiled formats (LLVM, Web Assembly) might use the native stack trace format instead of the Dart VMs for performance and usability reasons, for example.

[matanlurey]

Basically tl;dr - what you are asking for already exists in a way that is much easier to iterate on and is more guaranteed to work the same as more platforms become available

[matthew-carroll]

Thanks for the info. This continues to be interesting :)

This new information certainly changes the perspective quite a bit. Based on your description, I would tend to agree that this original ticket is misguided. The interesting thing is that it's misguided due to a complete lack of context on my part. For example, here is the official API docs for this toString() method:

https://api.flutter.dev/flutter/dart-core/StackTrace/toString.html

The information you mentioned might be available somewhere, but whatever my path was to get here, it was easy for me to remain ignorant of those important details that you described.

At a minimum, could this information be added to the toString() API docs, along with a reference to the official stack_trace package? If adding language API support is not a good idea, I would at least appreciate a world where developers can easily find out...

• the implicit importance of this particular toString() method
• why the language doesn't offer a structural solution
• where developers should go to find a structural solution

[matanlurey]

I think those are valid questions, but probably are a better fit for dart-lang/sdk.

There is also https://pub.dev/packages/native_stack_traces, I have no idea what this is though.

[lrhn]

It's definitely an SDK question, we don't want to specify the stack trace format in the language specification (for all the reasons Matan has mentioned, mainly that we want to just use native stack traces when compiling to JavaScript and other potential future native platforms).

Parsing the stack trace to figure out who called you is a kind of reflection, so I'm OK with that costing extra for the code doing so, and not adding the cost to other code which just propagates a stack trace and eventually prints it.
It's quite possible for the VM to add extra functionality to native stack traces, like iterating them, but that's also going to be a reflection and/or debugging-like operation, and definitely not something that is available cross-platform. I'd personally rather spend their developer resources on something which benefits all Dart users 😄.

[matthew-carroll]

Thanks for the replies. I've filed the following issue in the SDK repo:

#42927

I'm going to close this issue because it sounds like there is nothing more to do on the language front. If there is any internal tracking reason to leave this open then please feel free to re-open.