Problem (?) with Nashorn management of Error prototype

[David P. Caldwell]

No, I haven't been able to get any of the layers peeled off. I figured
since I was able to reduce it to running just a couple of commands
that would be sufficient for you to catch it in action and see what's
going on. I'm not sure what part of the surrounding stack is essential
yet.

> 1. Build the shell to a subdirectory called "jsh":
> jrunscript -e "load('https://bitbucket.org/davidpcaldwell/slime/raw/d04bd81/jsh/etc/jrunscript.js?relative=./install.jrunscript.js')"
> jsh
>
> 2. To run the test case with my workaround enabled:
> java -jar jsh/jsh.jar jsh/src/jsh/test/manual/errortype.jsh.js
>
> 3. To run the test case with my workaround disabled, exposing the
> error (on a UNIX-like system; translate for Windows as necessary):
> env DISABLE_NASHORN_ERROR_HACK=true java -jar jsh/jsh.jar
> jsh/src/jsh/test/manual/errortype.jsh.js


-- David P. Caldwell
http://www.davidpcaldwell.com/

On Tue, Oct 7, 2014 at 8:19 AM, A. Sundararajan
<sundararajan.athijegannathan at oracle.com> wrote:
> This is w.r.t this email:
>
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003582.html
>
> Hi,
>
> did you manage a simpler test case? Internal runtime errors like TypeError
> on function-call-on-undefined etc.  are created using Global.newTypeError,
> newURIError etc. - which actually create objects of specific impl. classes
> like NativeTypeError, NativeURIError and so on. This is as per the spec
> AFAIK - i.e., runtime can use "original" definitions of these constructors
> rather than the value fetched from current global's properties of same name
> ("Error", "TypeError" properties of global object). I don't recall any other
> place where there is specific prototype/constructor assumed/hard coded in
> nashorn.
>
> Thanks,
> -Sundar