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