fn:stack-trace: keep, drop, replace with $err:stack-trace ?

[ChristianGruen]

The current specification contains a diagnostic function called fn:stack-trace. Many other languages provide a similar function: The returned output can possibly help to understand which function calls led to an error during the evaluation of a code.

Still, I have strong doubts that it is a good decision to include this function in the standard:

The specification gives you a vast amount of freedom how to implement and optimize things. As a result, it’s completely feasible and reasonable to rewrite the following code…

declare function local:double($f) {
  $f * 2
};
(1 to 6) ! local:double(.)

…to (1 to 6) ! (. * 2) at compile time. If a user adds a fn:stack-overflow call in the function body, s·he would expect to find the function invocation of the original code representation in the output. As always, there are technical solutions to achieve this (store additional information in the evaluation tree on the original query; suppress optimizations when fn:stack-trace is found), but all of them can affect the runtime behavior and lead to different evaluation trees, hiding possible bugs in the implementation (which can be a reason to call fn:stack-trace at all).

A standard should provide a minimum amount of assurance that a function behaves similarly across different implementations. At this time, I don’t believe we can’t give that guarantee.

Related: #55, #686

– As an alternative, a stack trace could optionally be created by an implementation when an error is triggered.

[Arithmeticus]

I doubt that I am representative of the type of person who should influence this question. That said, if fn:stack-trace were made available, I would use it relatively often, certainly in development work and possibly in production.

[ChristianGruen]

@Arithmeticus Thanks. Out of interest: What would be productive use cases for the function? Would it be beneficial or limiting for you to have the stack trace generated by errors instead?

[Arithmeticus]

I have had to develop applications in environments where it is difficult (sometimes very difficult) to intercept the message listener when invoking an XSLT subprocess, and the ability to write in XSLT the stack trace to a secondary result document (<xsl:result-document>) would be useful. It's hard for me to say further, because I don't know what the output of fn:stack-trace would be, and it's only by playing around with it that I can discern other ways it might be used.

The option with errors would be a benefit. That is, bundling as an available variable within e.g. <xsl:catch>? Seems to make more sense.

[ChristianGruen]

To revive this discussion:

One pragmatic suggestion could be to replace fn:stack-trace with an $err:stack-trace variable in the catch clause (and a corresponding $err:map entry).

In general, when we add features to the standard, I think our rule of thumb should be that there will be at least two implementations that support it.

[rhdunn]

For reference, MarkLogic includes a stack trace as part of the error XML data in its catch block.

I've also just found that Oracle has a get-stack-trace method that returns a stack trace in a catch block, or empty sequence outside of the catch block. [1]

So there is existing support for this behaviour, just not via a standardized API/structure. Note that both MarkLogic and Oracle provide the stack trace as XML.

[1] https://docs.oracle.com/cd/E29584_01/webhelp/XQueryDev/src/rxqd_eutil_get-stack-trace.html

[ndw]

Consensus of the folks present in Prague: provide a stack trace in errors, but not as a stand alone function.