Stack traces when no LineNumberTable attribute exists...

General Discussions
#1

Sure, if there’s no LineNumberTable attribute to lookup into, the stack trace can’t give you a line number…
However why doesn’t the VM spit out the bytecode offset at which the Throwable occurred?

Seems logical if you can’t do the bytecode offset -> line number conversion, then you should just ‘do the best you can’, return the bytecode offset, and the let developer do the rest.
Unless I’m overlooking some VM argument that alters this behavior, potentially useful information is being discarded unnecessarily.

It doesn’t even seem to have been considered when the java.lang.StackTraceElement API was retrofitted in Java 1.4. (StackTraceElement only deals with line numbers, not bytecode offsets)

Anyone else encountered this, and wished for better stack traces?

:edit:

Quick search turned up this:
https://bugs.openjdk.java.net/browse/JDK-4185378

So I guess I’m not the only one…

#2

I wondered the same, and attributed it to the desired look-and-feel of the language.

You’re going to spook Joe Sixpack with bytecode offsets in his trusty stacktraces.

Slightly offtopic: stacktrace elements pointing to synthetic methods, pointing to [icode]Classy.java:1[/icode] are a similar minor pet peeve of mine. There’s no code at line one. Stop lying to me plz! While we’re at it, it surprises me how even (well) seasoned developers don’t grasp that a stacktrace ending with [icode] … 31 more[/icode] does not imply that information was dropped. It’s just deduplicated from the parent exception. HTH somewhat. :persecutioncomplex: