Reading Stacktrace in J2ME?

[Rhino]

Can anyone tell me how to decipher a J2ME stacktrace?

I am working on my first couple of J2ME applications. I'm using the Sun
Wireless Toolkit 2.2. When I crash my MIDlet, I get something like this:

startApp threw an Exception
java.lang.NullPointerException
java.lang.NullPointerException
at javax.microedition.lcdui.ChoiceGroup.<init>(+92)
at javax.microedition.lcdui.List.<init>(+61)
at MemberManager.constructMemberList(+18)
at MemberManager.startApp(+16)
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(+116)

Can someone tell me what the signed numbers in brackets mean and how I can
relate them to line numbers in my source code?

For instance, in this example, the NullPointerException happened in
MemberManager.constructMemberList and MemberManager.startApp but I can't
figure out what the +18 and +16 mean. I'm used to those being unsigned
integers that coincide with the line number in the source code where the
error took place. But lines 16 and 18 of MemberManager are NOT in the
constructMemberList and startApp methods, they are javadoc comments early in
the program.

How do I find which line of source code threw the exception?

I'd be very grateful for some help with this basic question; it would
certainly save me some time ;-)

--
Rhino
---
rhino1 AT sympatico DOT ca
"There are two ways of constructing a software design. One way is to make it
so simple that there are obviously no deficiencies. And the other way is to
make it so complicated that there are no obvious deficiencies." - C.A.R.
Hoare

 

[Darryl L. Pierce]

Can someone tell me what the signed numbers in brackets mean and how I can
relate them to line numbers in my source code?

The opcode. Don't ask me why the MIDP emulators do that. I think it's dumb
that they don't give you a line number...

How do I find which line of source code threw the exception?

The old fashioned way: you have to put System.out.println() statements into
the code in question and track it down from there...

--
/**
* @author Darryl L. Pierce <[email protected]>
* @see The Infobahn Offramp <http://mcpierce.multiply.com>
* @quote "Lobby, lobby, lobby, lobby, lobby, lobby..." - Adrian Monk
*/

 

[Rhino]

The opcode. Don't ask me why the MIDP emulators do that. I think it's dumb
that they don't give you a line number...

I'll go along with that! I suppose the developers sat down and weighed their
options: "Gee, what should we put in the stacktrace? The line number just
like every other version of Java and something which people can use, or the
opcode, which is useless to just about everyone? Okay, let's go with the
opcode....".

The old fashioned way: you have to put System.out.println() statements into
the code in question and track it down from there...

That's what I *have* been doing. I was hoping there was some way to convert
the info in the stacktrace to line numbers or reconfigure the toolkit so
that it produced line numbers but it looks like I'm out of luck. Oh well,
back to 1982 techniques....

Thanks for filling me in on this question Darryl!

Rhino

 

[Larry Barowski]

Can anyone tell me how to decipher a J2ME stacktrace?

I am working on my first couple of J2ME applications. I'm using the Sun
Wireless Toolkit 2.2. When I crash my MIDlet, I get something like this:

startApp threw an Exception
java.lang.NullPointerException
java.lang.NullPointerException
at javax.microedition.lcdui.ChoiceGroup.<init>(+92)
...

Can someone tell me what the signed numbers in brackets mean and how I can
relate them to line numbers in my source code?

These are byte code offsets for each method. There are probably
IDEs that will let you click on the stack dump lines and jump to
the referenced file and the line corresponding to the byte code
offset. We are currently adding J2ME capability to jGRASP and
it will have this feature.

You could look up the line numbers manually if there is some tool
that displays byte code offset vs. line number for class files. Also,
less conveniently, if you have a debugger that shows both line
number and byte code offset for the stack, you could step through
the methods until you find the byte offsets.

 

[Chris Uppal]

I'll go along with that! I suppose the developers sat down and weighed
their options: "Gee, what should we put in the stacktrace? The line
number just like every other version of Java and something which people
can use, or the opcode, which is useless to just about everyone? Okay,
let's go with the opcode....".

I doubt if JVM authors would want to include the extra overhead of finding and
decoding debugging information (from the class file) just to generate line
number info for each exception (even if it were done lazily in the exception's
toString() method, it's still extra code which takes up space). /Especially/
when it's presumably unlikely that anyone would leave debugging info in
classfiles intended to live on a resource-constrained device.

-- chris

 

[nagkumar]

Netbeans seems to have a solution

Hi,

This kind of stack trace with offset numbers are provided only during direct project invocation from wtk, however when the same application is run using netbeans IDE, the exact line number is provided for the same wtk configuration.

I wish netbeans to tell us what they do..

Regards,
Raja Nagendra Kumar,
C.T.O
Tejasoft
linkedin.com/in/nagkumar
- JavaME/Android/BlackBerry Offshore Excellence