I think the feature flag is a good approach for this. I run Rhino in an environment where users are aware they are running on Java, and frequently utilize Java libraries in their scripts, so I would not want to lose the current behavior, as it helps with troubleshooting.

Sounds good to me. This PR currently names the feature flag FEATURE_HIDE_WRAPPED_EXCEPTIONS and it is only used when JavaScript code catches an exception thrown by Java code. Potentially there could be other parts of Rhino that expose Java/Rhino implementation details to JavaScript code as well. What would be a good name for this feature flag? Could this feature flag be used to hide other Java/Rhino implementation details?

Wondering if you are also already disabling stuff like:

• Packages
• direct access to classes via org/java/com.xxxxx
• JavaImporter
• etc.

Just wondering if this calls for yet another, quite specific flag or if there's some other way we can be clever about this. For example only include the Java Exception details if the above stuff is also initiated

Good idea. We're already using Context.setClassShutter to hide all Java classes:

cx.setClassShutter(new ClassShutter() {
    @Override
    public boolean visibleToScripts(String className)
    {
        return false;
    }
});

so we could use ScriptRuntime.isVisible without adding a new ContextFactory flag:

                if (!isVisible(cx, javaException)) {
                    type = TopLevel.NativeErrors.InternalError;
                    errorMsg = javaException.getMessage();
                } else {
                    type = TopLevel.NativeErrors.JavaException;
                    errorMsg =
                            javaException.getClass().getName() + ": " + javaException.getMessage();
                }

Thoughts?

If you're not exposing any classes (visibleToScripts always returning false), how are you initializing your standard objects?

Because if you go through ScriptRuntime.initSafeStandardObjects (and never through ScriptRuntime.initStandardObjects), isn't the ability to access Java Classes disabled completely (without having to implement the classShutter)?

My idea was to only enable the Java Exception details inside JavaScript when the init was done through ScriptRuntime.initStandardObjects, which enables Java class access, so it would make sense to then also have access to the Java Exception details

Not sure if this would work for you and what others think about this approach

This seems like a pretty handy feature to me and looks good. But I'll see if others have opinions on the alternative approach that's being suggested for a day or so.

Because if you go through ScriptRuntime.initSafeStandardObjects (and never through ScriptRuntime.initStandardObjects), isn't the ability to access Java Classes disabled completely (without having to implement the classShutter)?

We use initSafeStandardObjects, but the ClassShutter is still used in ScriptRuntime.newCatchScope to avoid making the Rhino-specific properties javaException, rhinoException, and __exception__ available within the JavaScript catch scope.

This looks good to me. If no one else has any objections I'll merge it soon.