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.athijegannat...@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
> >>
>
>
