JavaSriptException now inherits from RhinoException which inherits from RuntimeException and as such it does not necessary to declare it.
Moreover, it is wrong to use it for the documentation purpose since a script can also throw EcmaError and WrappedException and a proper documentation would require to document those exceptions as well. But since almost all Rhino functions can potentially execute script code it means that wast majority of functions would bear the declarations, not only code overriding or calling explicitly Function.call/construct. And then the throw declarations would bring no information if it always would be "throws RhinoException". Thus it is better not to litter sources with the declarations at all.
This is based on code contributed to Rhino by AgileDelta, Inc, www.agiledelta.com and in particular by
Ethan Hugg
Terry Lucas
Milen Nankov
John Schneider
Thanks!
the later is stored in the factory and not in static variables.
For compatibility an instance of ContextFactory stored in static variables
is used to provide support for old Context.addContextListener etc. API.
The static instance of the factory is also used by Context.enter to create
Context instances providing simple way to customize Context: one just need
to initialize the global static factory.
Context.call(new ContextAction() {
public Object run(Context cx) { ... }
});
or similar alternatives.
It prevents bugs with missed Context.exit and provides room for optimization of Context association with current thread and simplify implementation of safe environment for execution of untrusted applets and scripts.
In addition, Rhino now supports global SecurityController that take precedence over any per/Context controllers so the application can setup the controller once and for all.
Now Context defines new method "call" that provide optimized version of the following code:
Context cx = Context.enter()
try {
callable.call(cx, scope, thisObj, args);
} finally {
Context.exit();
}
Since Function extends Callable, it can be passed to this method directly thus simplifying ScriptableObject.call method and Java adapter code.
The new interface is used in SecurityController implementation which allows to pass interpreted functions there directly as well removing the need to have intermediate class in Interpreter.
2. Catch VirtualMachineError so on out-of-memory/stack-overflow the shell will exit with System.exit(EXITCODE_RUNTIME_ERROR), not with 1. It will allow to distinguish cases when script tried to consume all available stack/memory with bugs in Rhino itself leading to NullPointerException etc.
3. Remove code to rethrow ThreadDeath from JavaScriptExcception since ThreadDeath is re-thrown by the engine itself.
Changing behavior of sealed objects to throw an exception on any attempt to modify them including changing values of existing properties. In the same time making object sealed does not affect read-only status of its properties which allows to override properties of objects with a sealed object as a prototype.
Rhino shell now accepts -sealedlib option to seal all standard objects.
