Changes the implementation of Error.captureStackTrace so that it does not need to create new Error()

[johnspackman]

This fixes a problem where a stack overflow will occur when the global Error class has been replaced, such as in the recent implementation of core-js polyfill (see https://github.com/zloirock/core-js).

Only recent revisions of core-js have triggered the stack overflow, and the polyfill is essential - the Qooxdoo.org project supports Rhino as a target and incorporating core-js is mandatory.

This change is 100% backwards compatible.

[gbrail]

I'm in favor of doing this.

To get the tests to pass, you'll need to ensure that "./gradlew check" passes. It looks like the formatting isn't what the "spotless" tool expects, and you can fix that by first running "./gradlew spotlessApply".

Thanks!

[gbrail]

Two other things:

1. It'd be great to see a way to test to verify that this is really fixed. First choice would be a test case that formerly produced a StackOverflow error.
2. I'm not sure how I feel about throwing an IllegalStateException in the case of recursion, because I'm not sure how well users of Rhino are going to be able to handle having Rhino throw raw Java exceptions instead of some sort of JavaScript error, like by throwing the exception produced by ScriptRuntime.constructError.

[johnspackman]

1. It'd be great to see a way to test to verify that this is really fixed. First choice would be a test case that formerly produced a StackOverflow error.

I came across it only when a minor-version upgrade to the core-js package was installed; and the polyfill is quite convoluted and spread over a number of lines. I'm not confident it'll be at all easy to reproduce without pulling in the core-js code.

OTOH the original Rhino code says that it was just trying to reuse the code from the constructor of Error - I don't know if something's changed, but the code seems more straightforward this way.

Would you be comfortable if there was unit tests to show that it still works this way, i.e. rather than test for the stack overflow, test instead that the captureStackTrace still works as expected?

2. I'm not sure how I feel about throwing an IllegalStateException in the case of recursion

No problem, also the unit tests and formatting

[johnspackman]

2. I'm not sure how I feel about throwing an IllegalStateException in the case of recursion

No problem, also the unit tests and formatting

Ah - hang on, the problem would be that throwing a JavaScript error would cause the stack overflow exception; that throw should (in theory at least) never be thrown any more, but I had to add it so that I could set a breakpoint and catch the problem. Probably best if I just delete it?

[johnspackman]

How do you debug the javascript code as it is being run by rhino? I've got "a" debugger but only one that works inside of my framework.

[gbrail]

Thanks for continuing to look at this. I have been able to use "normal" debuggers like the one built-in to VS Code with Rhino, but that's primarily to debug the Java code. For debugging the JavaScript directly it's a very different thing, although the debugger built in to Rhino (in the "toolsrc" directory) has given some people help in some circumstancesl.