-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fn:stack-trace: keep, drop, replace with $err:stack-trace ? #689
Comments
I doubt that I am representative of the type of person who should influence this question. That said, if |
@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? |
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 ( The option with errors would be a benefit. That is, bundling as an available variable within e.g. |
To revive this discussion: One pragmatic suggestion could be to replace 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. |
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 |
Consensus of the folks present in Prague: provide a stack trace in errors, but not as a stand alone function. |
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…
…to
(1 to 6) ! (. * 2)
at compile time. If a user adds afn: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 whenfn: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 callfn: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.
The text was updated successfully, but these errors were encountered: