Exception error

A

asit

Consider the following code snippets

import java.io.*;
public class MyQuestion1 {

public static void main(String[] args) {
System.out.println("Before try");
try {
}
catch(IOException t) {
System.out.println("Inside Catch");
}
System.out.println("At the End");
}

}

This shows following compiler error,
exception java.io.IOException is never thrown in body of corresponding
try statement

But why the following code is error free

public class MyQuestion2 {

public static void main(String[] args) {
System.out.println("Before try");
try {
}
catch(Throwable t) {
System.out.println("Inside Catch");
}
System.out.println("At the End");
}

}
 
J

Joshua Cranmer

asit said:
But why the following code is error free

Throwable includes the Error hierarchy, which can be thrown at pretty
much any time (e.g., ThreadDeath). I imagine InternalError could also be
thrown here as well in theory.
 
L

Lew

asit said:
Consider the following code snippets

import java.io.*;
public class MyQuestion1 {

public static void main(String[] args) {
System.out.println("Before try");
try {
}
catch(IOException t) {
System.out.println("Inside Catch");
}
System.out.println("At the End");
}

}

This shows following compiler error,
exception java.io.IOException is never thrown in body of corresponding
try statement

But why the following code is error free

public class MyQuestion2 {

public static void main(String[] args) {
System.out.println("Before try");
try {
}
catch(Throwable t) {
System.out.println("Inside Catch");
}
System.out.println("At the End");
}

}

Java mostly forbids catching checked exceptions that are not thrown, with the
exception of Exception. Unchecked exceptions, Errors and Throwables are allowed.
 
M

Mike Schilling

Joshua said:
Throwable includes the Error hierarchy, which can be thrown at pretty
much any time (e.g., ThreadDeath). I imagine InternalError could also
be thrown here as well in theory.

As well as OutOfMemoryError.
 
J

Joshua Cranmer

Mike said:
As well as OutOfMemoryError.

Probably not: the try block was empty, which means it's not going to be
doing any dynamic allocation (variable space allocation would happen on
method entry). Then again, it might be possible under some really
unlucky threading context switch order. Is OutOfMemoryError guaranteed
to be called on the same thread which made the allocation attempt?
 
M

Mike Schilling

Joshua said:
Probably not: the try block was empty, which means it's not going to
be doing any dynamic allocation (variable space allocation would
happen on method entry).

Is the Java heap distinghished from other JVM memory? Say that this JVM
implemenation allocates a record that says "I'm in a try block", and isn't
smart enough to optimize away this case. Say further that the allocation
fails. Should it throw an OOM or some other error that means "internal JVM
failure"?
 
J

Joshua Cranmer

Mike said:
Is the Java heap distinghished from other JVM memory? Say that this JVM
implemenation allocates a record that says "I'm in a try block", and isn't
smart enough to optimize away this case. Say further that the allocation
fails. Should it throw an OOM or some other error that means "internal JVM
failure"?

The class file contains all of the try/catch information in a separate
attribute, which the VM (judging from OpenJDK source code) appears not
to really concern itself with after method execution start until an
exception is thrown.

There might also be debugging allocation issues, now that I look at it,
but I wonder if that would just cause the VM to segfault. It would be
awfully hard to test though...
 
J

Joshua Cranmer

Thomas said:
It depends on the JVM implementation. For instance, it is fairly
standard for generational GC to maintain lists of generation-forward
pointers, i.e. pointers from an old to a younger generation. The simple
act of writing a reference into a field implies some handling of these
lists, which may trigger some heavy GC activity and an OutOfMemoryError.

The case in question would contain no actual bytecode of execution,
beyond a goto. No field references, therefore no chance to mess with GC.
Another possibility is that the JIT compiler may decide to switch from
interpreted to compiled code for that method precisely upon entering the
"try" block (e.g. it has reached its maximum count of interpreted
opcodes for that method); JIT compilation entails some dynamic
allocation. There are countless other possible sources of OOM.

The OpenJDK HotSpot VM appears to do JIT at method-level, which makes
the most sense to me; the only other JIT code I know about (Mozilla's
SpiderMonkey) also does at method-level.
I would be surprised -- internally, the JVM performs quite a lot of
memory-related activity, not all of which being on behalf of a specific
and well identified thread.

Reading the JLS:
If there is insufficient space to allocate the object, evaluation of the
class instance creation expression completes abruptly by throwing an
OutOfMemoryError (§15.9.6).

An (not necessarily `the', though) OutOfMemoryError therefore must be
thrown on the same thread. It could conceivably cause one to be thrown
on all threads, but the utility of this is circumspect.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top