Error Stack Column number

[Art Fiedler]

Without knowing all the internals of nashorn. I don't know if an internal
calling tree exists or how complicated it would be to build, but it seems
the runtime could track function calls and maintain its own stack.

CallNode before code is generated has the token/linenumber where it came
from, store a unique id of the callnode, with filename, line, column, in
the runtime. Then as a call node is executed push to the call stack the id
of the call node, and pop when call is complete... when the stack is
requested capture the current threads callnode id list (maybe use a thread
local?) match it up with the stored callnode id info map... merge/overwrite
stackelements in the stack trace gathered from Throwable.

Well, that's what just rolled off my head of how it could possibly be done.

-Arthur Fiedler

On Fri, Dec 2, 2016 at 4:09 AM, Sundararajan Athijegannathan <
sundararajan.athijegannathan at oracle.com> wrote:

> StackTraceElement being final is not the only issue here. How do to pass
> around & populate column numbers for the script frames?  That is the
> main issue here..
>
> -Sundar
>
> On 12/2/2016 3:00 PM, Art Fiedler wrote:
> > Yeah I almost mentioned that StackTraceElement doesn't provide a column
> > number to populate but removed that comment, thinking "well,
> > StackTraceElement could just be extended for NashornStackTraceElement",
> but
> > now looking at it I notice it's final. ugh. But it doesn't technically
> mean
> > an array of StackTraceElement's cant be converted to
> > NashornStackTraceElement's after getting the stack from the jvm, then
> > matching up script frames and populating additional information.
> >
> > -Arthur Fiedler
> >
> > On Fri, Dec 2, 2016 at 2:59 AM, Sundararajan Athijegannathan <
> > sundararajan.athijegannathan at oracle.com> wrote:
> >
> >> Error has columnNumber property - but as you've noted it is not always
> >> available :(  If the error is thrown from script code anywhere via
> >> ECMAScript throw statement, we do populate column number - because
> >> nashorn could compile the code appropriately to put column number!
> >>
> >> But, there are places in nashorn runtime code where ECMAScript errors
> >> are thrown. For example, RangeError thrown from deep inside nashorn
> >> runtime Java code! From those places, we can only recover java stack
> >> trace & populate properties of ECMA error object.  As java
> >> StackTraceElement objects do not have column number, we can't populate
> >> column number.
> >>
> >> -Sundar
> >>
> >> On 12/2/2016 2:06 PM, Art Fiedler wrote:
> >>> Your right it's still not standard even in the EMCAScript 2016, it just
> >>> seems to
> >>> be the commonality. When thinking java yes line only makes sense as
> >>> typically
> >>> one who writes java does not minify the code. When thinking javascript
> >>> however
> >>> minified code is quite normal and myfile:1 might mean 5000 other lines
> as
> >>> well.
> >>>
> >>> I looked into the source some to see if it actually is feasible to
> build
> >> my
> >>> own
> >>> stacktrace with file:line:column, however in the current state it seems
> >>> impossible! Nashorn actually uses java.lang.Throwable.getStackTrace()
> to
> >>> get the
> >>> stack and that ends up being native. The only place you can get the
> >>> columnNumber
> >>> is for the specific location the error was thrown. Keyword "thrown".
> >>>
> >>> If you noticed my previous sample new Error().columnNumber === -1 since
> >>> columnNumber is not populated... however if you throw & catch then...
> >>>     try { throw new Error(); }
> >>>     catch(e) { /* e.columnNumber === 6 */ }
> >>>
> >>> In my case with console.count(), the need for columnNumber is not the
> >>> location
> >>> of new Error() either, since the console.count() function would need
> the
> >>> callers file:line:col as that is where console.count() is called from.
> >>>
> >>> In the end I still think if the stack element is from a script it
> should
> >>> include
> >>> the column number like node.js, ff, edge all seem to be doing. Since a
> >> line
> >>> only
> >>> is useless when the script is minified. However considering that
> nashorn
> >> is
> >>> not
> >>> providing the stackTrace directly, I could see why the team may not
> want
> >> to
> >>> include the columnNumber. If you do however know of another way to get
> >> the
> >>> callers file:line:col please let me know. My second thought was to
> check
> >>> arguments.callee.caller for that info but no dice.
> >>>
> >>> -Arthur Fiedler
> >>>
> >>> We do not aim to provide complete compatibility with other JS
> >>>> implementations on the non-standard properties such as "stack". stack
> >>>> tries to mimic whatever is done for Java code (no column number for
> >>>> eg.). But, as you've noted there are enough information on Error
> objects
> >>>> via other properties like lineNumber, columnNumber, fileName. It
> should
> >>>> be possible to write a simple utility function to format stack string
> as
> >>>> desired for specific applications.
> >>>>
> >>>> Thanks,
> >>>> -Sundar
> >>>>
> >>
>
>