Runtime error in Java 6

[Jubert]

Hello,

This code compiles and runs under Java 5:

public class Java6RunTimeError {
public static void main(String[] args) {
System.out.println("\njust say hello\n");
String main_methodname =
Thread.currentThread().getStackTrace()[2].getClassName();
}
}


It gives a Runtime error under Java 6:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at Java6RunTimeError.main(Java6RunTimeError.java:4)

even when compiled with JDK6. Any clue?

Cheers

 

[Daniele Futtorovic]

Hello,

This code compiles and runs under Java 5:

public class Java6RunTimeError {
public static void main(String[] args) {
System.out.println("\njust say hello\n");
String main_methodname =
Thread.currentThread().getStackTrace()[2].getClassName();
}
}


It gives a Runtime error under Java 6:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at Java6RunTimeError.main(Java6RunTimeError.java:4)

even when compiled with JDK6. Any clue?

You aren't running this in a console, now are you?

IOW, I doubt this is a difference between 1.5 and 1.6, but rather of
having a (de)bugger or some other layer in-between.

 

[Patricia Shanahan]

Hello,

This code compiles and runs under Java 5:

public class Java6RunTimeError {
public static void main(String[] args) {
System.out.println("\njust say hello\n");
String main_methodname =
Thread.currentThread().getStackTrace()[2].getClassName();
}
}


It gives a Runtime error under Java 6:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at Java6RunTimeError.main(Java6RunTimeError.java:4)

even when compiled with JDK6. Any clue?

You aren't running this in a console, now are you?

IOW, I doubt this is a difference between 1.5 and 1.6, but rather of
having a (de)bugger or some other layer in-between.

More generally, accessing a stack trace by fixed index, without looking
at its length, has an inherent risk of ArrayIndexOutOfBoundsException.

"Some virtual machines may, under some circumstances, omit one or more
stack frames from the stack trace. In the extreme case, a virtual
machine that has no stack trace information concerning this throwable is
permitted to return a zero-length array from this method."

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html#getStackTrace()

Even if starting the same job under the same conditions, the two JREs
could use different numbers of stack frames. That is in addition to the
possibility that the same JRE uses a different number of frames under
different conditions.

Patricia

 

[Arne Vajhøj]

This code compiles and runs under Java 5:

public class Java6RunTimeError {
public static void main(String[] args) {
System.out.println("\njust say hello\n");
String main_methodname =
Thread.currentThread().getStackTrace()[2].getClassName();
}
}

It gives a Runtime error under Java 6:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at Java6RunTimeError.main(Java6RunTimeError.java:4)

even when compiled with JDK6. Any clue?

I would say that the code is invalid in any Java version.

It just accidentally happen to have main at index 2 in 1.5.

Arne

 

[Roedy Green]

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at Java6RunTimeError.main(Java6RunTimeError.java:4)

see
http://mindprod.com/jgloss/runerrormessages.html#ARRAYINDEXOUTOFBOUNDS

 

[Roedy Green]

Thread.currentThread().getStackTrace()[2].getClassName();

If you are using Jet, the stack trace and line number info is not
available. I suggest you have a peek at what getStackTrace gave you,
rather than just presuming its depth.

 

[ldv]

If you are usingJet, the stack trace and line number info is not
available.

Your statement would have been correct if you added "by default". Here
is an excerpt from Excelsior JET User's Guide:

--------------------------------------------------
By default, Throwable.printStackTrace() methods print a few fake
elements, because stack tracing is disabled in the JET Runtime.
However, some third-party APIs may rely on stack trace printing. One
example is the Log4J API that provides logging services.

The JET Runtime supports two modes of stack trace printing: minimal
and full. In the minimal mode, line numbers and names of some methods
are omitted in call stack entries, but class names are exact. In some
cases, it is enough for stack trace-dependent APIs to work, e.g. the
Log4J API operates flawlessly in this mode.

Note: Enabling stack trace may negatively impact performance, if
exceptions are thrown and caught repeatedly.

In the full mode, the stack trace info includes all line numbers and
method names. However, enabling the full stack trace has a side effect
of substantial growth of the resulting executable size by
approximately 30%.
--------------------------------------------------

 

[Andreas Leitgeb]

Note: Enabling stack trace may negatively impact performance, if
exceptions are thrown and caught repeatedly.

Bugs in the code are probably already "negatively impacting performance" and,
worse still, correctness "if exceptions are thrown and caught [and gosh, let's
hope they're caught - surely we catch all our exceptions, right?] repeatedly".
That many exceptions almost certainly indicates serious problems.

Not all exceptions are used for reporting/escalating bugs.

 

[Lew]

Bugs in the code are probably already "negatively impacting performance" and,
worse still, correctness "if exceptions are thrown and caught [and gosh, let's
hope they're caught - surely we catch all our exceptions, right?] repeatedly".
   That many exceptions almost certainly indicates serious problems..

Not all exceptions are used for reporting/escalating bugs.

Other uses of exceptions tend to be an antipattern. Use of
conditional checks is usually better.

This is especially true when a program emits gobs and gobs of
exceptions. That is almost certainly not due to correct programming.
Either there are bugs or the programmer is relying too much on
exceptions instead of prevention.

Still the most common reason to have exceptions is the presence of
bugs. Note that I said "probably" about the presence of bugs, not
"certainly". I would rate the probability as very high.

 

[Mike Schilling]

Bugs in the code are probably already "negatively impacting
performance" and, worse still, correctness "if exceptions are
thrown and caught [and gosh, let's hope they're caught - surely we
catch all our exceptions, right?] repeatedly". That many
exceptions
almost certainly indicates serious problems.

Not all exceptions are used for reporting/escalating bugs.

Other uses of exceptions tend to be an antipattern. Use of
conditional checks is usually better.

Unfortunately, exceptions that are expected (and thus caught and
ignored) abound in code that you can't do anything about, like the JDK
classes. Try running some Java program under a debugger that breaks
on all exceptions and you'll see what I mean.

 

[Mike Schilling]

There's one sensibility for application development, and another for
API development. The API part throws Exceptions, in part because an
API writer has to be sure to lock down future, unguessable (ab)uses
of the library. The application part "knows" its own logic, and
what
conditions cause an API call to throw an Exception, so it can and
should guard against those conditions /a priori/, not permitting the
Exception. Often, not always.

[... Much good discussion of the use of Exceptions clipped]

Regardless, it happens that as a matter of brute fact many more
exceptions are thrown than one might expect, so optimizing the
creation of exceptions (by not filling in their stack traces) really
does optimize CPU use.

 

[Andreas Leitgeb]

There's one sensibility for application development, and another for API
development. The API part throws Exceptions, in part because an API writer
has to be sure to lock down future,...

It was about *really-thrown-and-caught* exceptions, not about potentially
thrown exceptions.

Errors are for a graceful exit from the program, or module. Things are too
fubared to return to the main algorithmic flow.

I wonder, if there exists an english dictionary, that contains "fubar"
(yes, I know what it means.) as a verb, that doesn't also contain other
abbreviated (or 'leet) speek.

 

[Lew]

I wonder, if there exists an english dictionary, that contains "fubar"
(yes, I know what it means.) as a verb, that doesn't also contain other
abbreviated (or 'leet) speek.

"fubar" predates leetspeek by decades.

 

[Lew]

I wonder, if there exists an english dictionary, that contains "fubar"
(yes, I know what it means.) as a verb, that doesn't also contain other
abbreviated (or 'leet) speek.

<http://en.wiktionary.org/wiki/FUBAR>

 

[Andreas Leitgeb]

"fubar" predates leetspeek by decades.

Perhaps leet-speak as it often shows up here, but I vaguely
remember from school, that phonetic-abbreviation-speek
e.g.: "i o u" (for "I owe you") was even older than WWII.

The wiktionary also mentions IOU, but not it's age.

 

[John W Kennedy]

Perhaps leet-speak as it often shows up here, but I vaguely
remember from school, that phonetic-abbreviation-speek
e.g.: "i o u" (for "I owe you") was even older than WWII.

The wiktionary also mentions IOU, but not it's age.

ca. 1610-1620, actually.

"Fubar" is an acronym, and acronyms (except in Hebrew) almost never
antedate WWII. Abbreviations, on the other hand, can be traced back as
far as writing. "IOU" is neither one, of course.