Try/Catch causes an "Unresolved Jump Label" exception

[GoogleCodeExporter]

What steps will reproduce the problem?
1. In JavaScript use a try/catch around the entire code in a file
2. compile

What is the expected output? What do you see instead?

Any errors through should be caught.

What version of the product are you using? On what operating system?

Minijoe v1.0 + Windoze X-peeper

Please provide any additional information below.

CODE:

try {
  .... any code here
} catch (e) {
  print(e);
}

STACKTRACE:

com.google.minijoe.compiler.CompilerException: Unresolved Jump Label:
finally=481523300 at line: 0
    at
com.google.minijoe.compiler.visitor.CodeGenerationVisitor.writeCodeBlock(+126)
    at com.google.minijoe.compiler.visitor.CodeGenerationVisitor.visit(+90)
    at com.google.minijoe.compiler.Eval.compile(+61)
    at net.xxx.j2me.xxx.xxxEnvironment.compile(+82)
    at net.xxx.j2me.xxx.xxxEnvironment.runScript(+4)
    at net.xxx.j2me.xxx.xxxEnvironment.<init>(+467)
    at net.xxx.j2me.xxx.xxx.startApp(+116)
    at javax.microedition.midlet.MIDletProxy.startApp(+7)
    at com.sun.midp.midlet.Scheduler.schedule(+270)
    at com.sun.midp.main.Main.runLocalClass(+28)
    at com.sun.midp.main.Main.main(+80)

** package/product names and domain changed for privacy.

Original issue reported on code.google.com by aDeeperB...@gmail.com on 24 Apr 2009 at 2:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It would be very helpful if you were to give a ECMA-262 spec version MiniJoe is
written to so as to better determine if something is a bug or a feature not yet
implemented. Thanks!

Original comment by aDeeperB...@gmail.com on 24 Apr 2009 at 2:45

[GoogleCodeExporter]

Does changing line 848 of CodeGeneratorVisitor.java to the following fix this:

currentTryLabel = statement.catchBlock != null ? "catch" : "finally";

Original comment by cwoffen...@gmail.com on 27 Apr 2009 at 2:49

[GoogleCodeExporter]

Answering myself... no it doesn't.

Original comment by cwoffen...@gmail.com on 28 Apr 2009 at 12:11

[GoogleCodeExporter]

When you get to this line;

currentTryLabel = statement.catchBlock == null ? "catch" : "finally";

The catchBlock is not null and its line number is '0' making me think that the 
issue
happens earlier in the compile process.

If you add the finally clause this exception no longer is thrown, thus 
'finally' is
required! Hopefully this will help us track down the issue.

thx, jb

Original comment by aDeeperB...@gmail.com on 28 Apr 2009 at 3:18

[GoogleCodeExporter]

The following stacktrace happens when you add the 'finally' clause. Line 86 is 
only
line in the 'catch' clause and is not a error. The code in the finally clause
executes without error and ids the same as line 86...

ST1: com.google.minijoe.compiler.ast.BlockStatement@1cb37664
ST2: 0
com.google.minijoe.sys.JsException: Error at line 86 (pc:0x26d): Error: [object 
Object]
    at com.google.minijoe.sys.JsFunction.eval(+2549)
    at com.google.minijoe.sys.JsFunction.exec(+70)
    at net.subNoize.j2me.xxx.xxxEnvironment.runScript(+8)
    at net.subNoize.j2me.xxx.xxxEnvironment.<init>(+467)
    at net.subNoize.j2me.xxx.xxx.startApp(+115)
    at javax.microedition.midlet.MIDletProxy.startApp(+7)
    at com.sun.midp.midlet.Scheduler.schedule(+270)
    at com.sun.midp.main.Main.runLocalClass(+28)
    at com.sun.midp.main.Main.main(+80)

Original comment by aDeeperB...@gmail.com on 28 Apr 2009 at 3:24

[GoogleCodeExporter]

Setting it to != does fix it... but then it just shows up another issue (the 
catch
block is then always called). I don't have the source right now but look at the 
code
generator where the TRY_CALL instruction is written, then change the GO to an 
IF. Let
me know if that works for you.

Original comment by cwoffen...@gmail.com on 28 Apr 2009 at 5:15

[GoogleCodeExporter]

Changing the write from XOP_GO to XOP_IF does correct the problem but...

    if (currentTryStatement == null) {
      writeXop(JsFunction.XOP_CALL, expression.arguments.length);
    } else {
      writeXop(JsFunction.XOP_TRY_CALL, expression.arguments.length);
      writeJump(JsFunction.XOP_IF, currentTryStatement, currentTryLabel);
    }

Now if an exception is thrown you get the following stackTrace;

com.google.minijoe.sys.JsException: Error at line 89 (pc:0x284): Error: [object 
Object]
    at com.google.minijoe.sys.JsFunction.eval(+2549)
    at com.google.minijoe.sys.JsFunction.exec(+70)
    at net.subNoize.j2me.xxx.xxxEnvironment.runScript(+8)
    at net.subNoize.j2me.xxx.xxxEnvironment.<init>(+467)
    at net.subNoize.j2me.xxx.xxx.startApp(+115)
    at javax.microedition.midlet.MIDletProxy.startApp(+7)
    at com.sun.midp.midlet.Scheduler.schedule(+270)
    at com.sun.midp.main.Main.runLocalClass(+28)
    at com.sun.midp.main.Main.main(+80)

I wish the numbers on these stacktraces actually referred to a line number or I 
could
be more help!

Original comment by aDeeperB...@gmail.com on 28 Apr 2009 at 6:48

[GoogleCodeExporter]

And you get the exception in combination with changing this line:

currentTryLabel = statement.catchBlock != null ? "catch" : "finally";

I'll check tomorrow if I changed anything else, but I thought I had this 
working.

Original comment by cwoffen...@gmail.com on 28 Apr 2009 at 8:15

[GoogleCodeExporter]

Thanks for the help! The two changes combined work as advertised;

    if (currentTryStatement == null) {
      writeXop(JsFunction.XOP_CALL, expression.arguments.length);
    } else {
      writeXop(JsFunction.XOP_TRY_CALL, expression.arguments.length);
      writeJump(JsFunction.XOP_IF, currentTryStatement, currentTryLabel);
    }

AND

    currentTryLabel = statement.catchBlock != null ? "catch" : "finally";

Will you be submitting this back to the code base? If not we need to alert the 
guy in
charge. Thanks again!

Original comment by aDeeperB...@gmail.com on 29 Apr 2009 at 12:12

[GoogleCodeExporter]

I assume only the project owner can commit? Regardless, the fix works for me and
doesn't appear to have any side effects.

Original comment by cwoffen...@gmail.com on 29 Apr 2009 at 12:28

[GoogleCodeExporter]

Hi,

thanks for the fix! 

I have committed the changes to SVN.

Original comment by stefan.haustein on 4 May 2009 at 11:57

• Changed state: Fixed