until JS_DestroyRuntime is called (68450, r=rginda, sr=jband).
- NUL-terminate tagbuf in tagify, for the HTML helpers such as string.big()
(66648, r=timeless, sr=jband).
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?
- Remove bogus JS_ASSERT(!outermost) from the code that deals with a "#n="
type string being returned from js_EnterSharpObject, where the hash entry
is not yet sharp (because we haven't seen the object twice during depth
first search). This case trivially arises for the outermost object in,
e.g., 'o={}; o.foo=o; uneval(o)'.
- Avoid parenthesizing #n={...} object initializers for uneval, as they are
not ambiguous (whereas {foo:1}, e.g., is ambiguous because it could be a
block statement containing a labeled expression statement, or it could be
an object initializer).
- Death to tabs!
Re: [Rhino in Java] compiling .js to class file gives "bad local" error
Date:
Wed, 31 Jan 2001 09:41:45 +0100
From:
"Sylvia E. Schleutermann" <ses@h-m-s.com>
Organization:
.hms Health Management Systems
Newsgroups:
netscape.public.mozilla.jseng
References:
1 , 2
I have found out some more. Looking really quickly over the JVM specs, I
found that
indeed the astore-command requires that the variables index be below 128.
However,
the book also said that if more index space is needed, a "wide" command can
be used to
be able to address up to 65xxx variables.
Question: is there a possibility to integrate this "wide"-command into the
class compiler?
Some option, that can be set? Or am I on the wrong tracks?
Please help, since I want to avoid spreading the script over many classes to
avoid the
size limitation. Cheers, Sylvia
Sylvia E. Schleutermann <ses@h-m-s.com> wrote in message
news:956sv9$9g53@secnews.netscape.com...
> I have found out that it is definitely the number of variables.
> I removed all variables and then the script compiled into class files
> with one base class and inner classes for each function in the script.
>
> What is the limitation exactly, i.e. does anyone know how many (global)
> variables
> I can use? Or is there some other kind of work around?
>
> Cheers, Sylvia
>
>
> Sylvia E. Schleutermann <ses@h-m-s.com> wrote in message
> news:956qtv$6kh3@secnews.netscape.com...
> > Hello,
> > when compiling a *.js file to class file, I get a "bad local" runtime
> > exception.
> > Stepping through the source, the following happens in reverse order:
> >
> > Codegen.xstore (75, 58, 209)
> > -> in the switch - default case, there is a comparison
> > for local (=209), which is compared to Byte.MAX_VALUE (=127).
> > When greater, the above exception is thrown.
> >
> > Codegen.astore (209)
> > -> calls Codegen.xstore (ByteCode.ASTORE_0, ByteCode.ASTORE, 209)
> >
> > Codegen.generatePrologue (<context>, <tree>, true, -1) // -1 is
> > directParameterCount
> > -> sets itsZeroArgArray = getNewWordLocal(); // here, the 209 is
> > produced
> > -> calls astore (itsZeroArgArray)
> >
> > From what I can read from the source code, the 209 seems to be a counter
> for
> > "locals", perhaps
> > local variables?? The function that is being compiled does initialize
many
> > variables - would it help
> > to move the initialize code out of the function into separate code
blocks?
> >
> > The function looks like this
> >
> > function rule_Disclaimer()
> > {
> > try { VAR1 = <init code 1>;} catch (exception) { VAR1 = <default
init
> > code 1>; }
> > try { VAR2 = <init code 2>;} catch (exception) { VAR2 = <default
init
> > code 2>;}
> > ... (about 58 such variables)
> >
> > var cond = true;
> >
> > < rest of code>
> > }
> >
> > When I compile the script for interpreted mode, all works well. The
> > variables VAR1 to VAR58 are to be global
> > variables (global to the whole script).
> >
> > I appreciate any help! Thanks, Sylvia
> >
> >
>
>
