gecko-dev/js
nboyd%atg.com 82bd85bfce Fix for problem:
Subject:
             Rhino Exception Handling: Inconsistency btw Old/New Versions of 1.5
        Date:
             Mon, 05 Feb 2001 06:07:07 -0800
       From:
             Timothy Bergeron <bergeron@resumerabbit.com>
 Organization:
             Another Netscape Collabra Server User
 Newsgroups:
             netscape.public.mozilla.jseng




I've been using Rhino for about a year with almost no problems. However,
I downloaded the latest Rhino tip (rhino15R2pre) and discovered a
significant difference in exception handling.

I rely heavily on JavaScript code like the following:

try {
   var em  = new ExceptionMaker();
   em.npe();  // method throws a java.lang.NullPointerException
   //em.ae();  // method throws a Packages.AutomationException
}
catch (e if (e instanceof java.lang.NullPointerException)) {
   java.lang.System.out.println("Caught a NullPointerException");
   e.printStackTrace();
}
catch (e if (e instanceof Packages.AutomationException)) {
   java.lang.System.out.println("Caught an AutomationException");
}
catch (e) {
   java.lang.System.out.println("Caught an unexpected exception: "+e);
}
finally {
   java.lang.System.out.println("Finally!");
}

Previous Rhino versions worked as expected. The exception thrown from
within the host object would be caught and the appropriate actions could
be taken.

With the most recent tip, the thrown exceptions simply are not caught
within the JavaScript. They propagate back to the Java function invoking
the (in my case) Context.evaluateReader() method.

Running the above JS fragement with the older tip displayed the
following stack trace (when the NullPointerException was caught):

Rhino Version: JavaScript-Java 1.5 release 1 2000 03 15
Caught a NullPointerException
java.lang.NullPointerException
        at java.lang.Throwable.<init>(Throwable.java:84)
        at java.lang.Exception.<init>(Exception.java:35)
        at java.lang.RuntimeException.<init>(RuntimeException.java:39)
        at
java.lang.NullPointerException.<init>(NullPointerException.java:45)
        at ExceptionMaker.jsFunction_npe(ExceptionMaker.java:13)
        at java.lang.reflect.Method.invoke(Native Method)
        at
org.mozilla.javascript.FunctionObject.call(FunctionObject.java:497)
        at
org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1205)
        at org.mozilla.javascript.gen.c1.call(exception.js:3)
        at org.mozilla.javascript.gen.c1.exec(exception.js)
        at
org.mozilla.javascript.Context.evaluateReader(Context.java:739)
        at js.main(js.java:14)
Finally!

When run with the latest tip, the output is:

Rhino Version: JavaScript-Java 1.5 release 1 2000 03
15                                          Finally!
Exception in thread "main" java.lang.NullPointerException
        at java.lang.Throwable.<init>(Throwable.java:84)
        at java.lang.Exception.<init>(Exception.java:35)
        at java.lang.RuntimeException.<init>(RuntimeException.java:39)
        at
java.lang.NullPointerException.<init>(NullPointerException.java:45)
        at ExceptionMaker.jsFunction_npe(ExceptionMaker.java:13)
        at inv2.invoke()
        at
org.mozilla.javascript.FunctionObject.doInvoke(FunctionObject.java:843)
        at
org.mozilla.javascript.FunctionObject.call(FunctionObject.java:486)
        at
org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1199)
        at org.mozilla.javascript.gen.c1.call(Unknown Source)
        at org.mozilla.javascript.gen.c1.exec(Unknown Source)
        at
org.mozilla.javascript.Context.evaluateReader(Context.java:778)
        at js.main(js.java:14)

Curiously, both Rhino versions seem to be returning the same string from
Context.getImplementionVerison();

Anyway, the results from the two runs are clearly different: In the
first case, the exception is thown, the correct catch block is invoked
(hence the stace trace), and the finally block is invoked. In the second
case, the exception is thrown, the finally block is invoked, and the
exception is handled by the calling Java method rather than being
handled by the JavaScript code.

After some research, it appears this change was introducted by a
modification to FunctionObject.call()  (See
http://bugzilla.mozilla.org/show_bug.cgi?id=64788) which used to have:

       try {
            Object result = (method != null)
                            ? method.invoke(thisObj, invokeArgs)
                            : ctor.newInstance(invokeArgs);
            return hasVoidReturn ? Undefined.instance : result;
        }

but now has:

            Object result = method == null ?
ctor.newInstance(invokeArgs)
                                           : doInvoke(thisObj,
invokeArgs);

If I comment out the new code and replace it with the old, the expected
exception handling returns. Is this just an oversight or the new
expected behavior? Are there any negative side effects (other then the
speed decrease in method invocation) if I use the latest tip but use the
old method invocation procedure in FunctionObject.call() rather than the
new?
2001-02-08 18:56:58 +00:00
..
benchmarks Add benchmarks. 1999-06-04 18:44:17 +00:00
js2 Fixed case, sorry 2001-02-02 01:08:06 +00:00
jsd NOT PART OF SEAMONKEY BUILD - removed misplaced semi-colon added by toshok on 6 Sep 1999 which had converted a conditional block into a non-conditional block and made the debugger completely non functional 2000-02-19 02:34:05 +00:00
jsdj updated license boilerplate to xPL 1.1, a=chofmann@netscape.com,r=endico@mozilla.org 1999-11-06 02:47:15 +00:00
jsj
macbuild Removing dead .toc files. Not part of build. a=sfraser. 2001-01-03 01:32:06 +00:00
ref
rhino Fix for problem: 2001-02-08 18:56:58 +00:00
semantics Added more semantics 2001-02-07 05:08:44 +00:00
src Fix for bug 44009 (r=rogerl, sr=shaver) 2001-02-06 23:19:44 +00:00
tests Exported functionality common to RegExp tests to new file js/tests/ecma_3/RegExp/shell.js 2001-02-08 04:04:48 +00:00
.cvsignore more anal tricks. 1999-06-26 05:01:40 +00:00
landbranch.pl
Makefile.in Fix fdlibm/mozjs dependency problem by making sure that fdlibm is always built before mozjs. 2001-02-04 06:27:59 +00:00
makefile.win updated license boilerplate to xPL 1.1, a=chofmann@netscape.com,r=endico@mozilla.org 1999-11-06 03:40:37 +00:00