netscape.javascript.JSException is never thrown in body of corresponding tr
I have the following try/catch block:
try
{
netscape.javascript.JSObject.getWindow(this.applet).eval("ClkExcept(" + nId.toString() +")");
}catch(netscape.javascript.JSException e){}
Which, for as long as I have compiled (until recently) compiled fine. However, when I recently had to recompile the classes containing this code because of an unrelated issue, I now get a message from the compiler stating that exception netscape.javascript.JSException is never thrown in body of corresponding try statement. I am attempting to use the latest 1.3.1_XX SDK (I must compile with some build of 1.3.1), but have run into this compiler message with all builds of 1.3.1 that I have tried. All documentation I can locate for the netscape.javascript.JSObject class states that the GetWindow() function can throw an exception of type netscape.javascript.JSException.
Has anyone seen this before, or does anyone have any suggestions on how to get the compiler working correctly?
*bump*nobody wants these duke dollars?
> Has anyone seen this before, or does anyone have any> suggestions on how to get the compiler working> correctly?Have you removed the try catch block and seen if it compiles correctly?
The compiler is working correctly. If it says the exception can't be thrown, it can't be thrown. Just get rid of the try/catch.
This code has not been edited in two years, but has been recompiled numerous times since then (until today) without any compiler messages pertaining to this try/catch block. I know for a fact that the GetWindow() function can throw a JSException. If I remove the try/catch block and there is a problem with the javascript function that is called on the page hosting my applet there would obviously be an exception to catch. Removing the try/catch block is not a solution.
> Removing the try/catch block is> not a solution.Well:1. You don't do anything with the caught exception.2. The compiler doesn't think it should be there so at the moment it is your word against the compiler.
Yes, I am trying to find out why the compiler does not believe that the exception can occur.
From the documentation for the netscape.javascript.JSObject class which I located at http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:LiveConnect_Overview:Java_to_JavaScript_Communication:Using_the_LiveConnect_Classes:
Also, any time you use JavaScript objects in your Java code, you should put the call to the JavaScript object inside a try...catch statement which handles exceptions of type netscape.javascript.JSException. This allows your Java code to handle errors in JavaScript code execution which appear in Java as exceptions of type JSException.
This seems to me to state quite clearly that I am attempting to catch the correct exception type. While I realize that the compiler has more credibility than I do, I believe that my code is correct and I am hoping to find out why code that has not changed in some time would suddenly generate this particular compiler message.
> This code has not been edited in two years, but has
> been recompiled numerous times since then (until
> today) without any compiler messages pertaining to
> this try/catch block. I know for a fact that the
> GetWindow() function can throw a JSException.
Have you changed compilers recently?
Have you tried compiling a brand new tiny test program in a different directory, with an explicit -classpath arg that contains only that relevant jar file, and no other classes in the directory?
Have you tried extracting the class file from the jar, running it through a decompiler, and seeing what it says about the exception?
> If I
> remove the try/catch block and there is a problem
> with the javascript function that is called on the
> page hosting my applet there would obviously be an
> exception to catch. Removing the try/catch block is
> not a solution.
You could try catching Exception instead. That will pass the compiler, because Exception includes RuntimeException and its descendants, and the compiler can't know that those won't be thrown, since they're unhecked. I'd consider that a last-ditch hack though, and wouldn't do it unless I'd thoroughly investigated first.
Also, have you tried compiling with a newer copmiler, just to find out if it is in fact a bug in that particular 1.3.1 compiler?
> Yes, I am trying to find out why the compiler does
> not believe that the exception can occur.
>
> From the documentation for the
> netscape.javascript.JSObject class which I located at
Javadocs can lie. I'd doubt them before I'd doubt the compiler.
I compiled a later version of my applet last month using the 1.5.0_10 SDK, which did not generate any such compiler messages. Unfortunately, I am stuck using 1.3.1 for the version of the applet I am currently attempting to compile. I tried the 1.3.1, 1.3.1_09, 1.3.1_17 and 1.3.1_20 SDK and received the same compiler message each time.
I created a test class in a new directory containing the .jar with the netscape.javascript.JSObject class and received the same compiler message.
I'm willing to try decompiling the class to see what's in there, however I have not done this before. I will attempt to do so and see what I come up with.
> I created a test class in a new directory containing
> the .jar with the netscape.javascript.JSObject class
> and received the same compiler message.
Okay, then it is looking like a compiler bug. You'll probably have to go with catching Exception.
> I'm willing to try decompiling the class to see
> what's in there, however I have not done this before.
> I will attempt to do so and see what I come up with.
At this point that is most likely an academic exercise, since the above test appears to confirm that it's not something weird in the classpath, environment, etc. for your app.
looks like I'll have to go with catching the generic exception...not sure quite what the issue was, but oh well.1 duke to zadok (because he at least posted), the other 9 to jverd
One other question: Are you sure that the library in question was compiled with no later than 1.3.1? If the class file is in a newer format than your 1.3.1 compiler can handle, it may be incorrectly interpreting something. If you try to run it in 1.3.1, you'll get a "bad class version" or somesuch error, but I don't know if the compiler gives those. (You'd think it should, but I won't make any assumpions.)
I did not receive any bad class version compiler messages, however, I'm not sure how to determine what compiler version a particular jar was compiled with so I can't absolutely say that it wasn't created with a more recent compiler.
> I did not receive any bad class version compiler
> messages, however, I'm not sure how to determine what
> compiler version a particular jar was compiled with
> so I can't absolutely say that it wasn't created with
> a more recent compiler.
Couple things to try:
* Get a class that you know was compiled with a newer version, and have your class depend on it. Try to compile your class with that other class in the classpath, and see if the compiler complains.
* Make a tiny test program that uses something in that jar file. Probably even just Class.forName would do it. Compile it with 1.3.1, and try to run it. If it runs without complaint, then the lib was copmiled with a compatible version.
