Exceptions thrown programatically or by JVM?

[Per Radfe]

How do you know whether an exception is thrown by the application (programmatically?) or thrown by the JVM?

For example IllegalStateException is thrown programmatically. Why?

I need some rule to hook things up to.

[subodh gupta]

I dont understand what do you mean by this question can you make your self little more clear?

For hints:
1) A program can throw an exception by using the keywords throws and throw.
2) And if their is any unhandled exception in your program it be handled by the JVM.(JVM act as last catcher for the exceptions)

[suresh mulagala]

IllegalStateException is subclass of RuntimeException and are usually bugs of improper us of the API. Such as tying to call a method on a null object such as :

List getSomeList(){
return null;
}
int lst = getSomeList().size(); // will throw a null pointer exception

These are not meant to be caught but fixed. But having said that it can still be caught and handled programatically.

[Jesper de Jong]

Anything that extends Throwable (exceptions, errors etc.) can be thrown by your own application with the "throws" keyword. There isn't a special set of exceptions that is thrown only by the JVM or only by the application.

[Adam Schaible]

Essentially the JVM catches your uncaught exceptions, and terminates. Exceptions will "bubble" up the call stack until it's either caught by calling code, or is caught by the jvm.

When you compile:

public static void main(String[] args...){
}

The compiler changes it to:

public static void main(String[] args...) throws Exception {
}

Your calling code then throws the exception to the JVM, it's caught by the JVM, flushed to the error stream, and exits.

[ahmed yehia]

Originally posted by Adam Schaible:

When you compile:
public static void main(String[] args...){
}
The compiler changes it to:
public static void main(String[] args...) throws Exception {
}

Not correct, the Compiler didnt supply a throws clause, unless you explicitly provide one.

[suresh mulagala]

Originally posted by Adam Schaible:
Essentially the JVM catches your uncaught exceptions, and terminates. Exceptions will "bubble" up the call stack until it's either caught by calling code, or is caught by the jvm.

When you compile:

public static void main(String[] args...){
}

The compiler changes it to:

public static void main(String[] args...) throws Exception {
}

Your calling code then throws the exception to the JVM, it's caught by the JVM, flushed to the error stream, and exits.

How do you know what the compiler appends? checking in a de-compiler? Just curious...

[Adam Schaible]

De-compile your code, the compiler adds the throws clause.

[ahmed yehia]

If the Compiler do that, then it wouldnt require me to handle code that may throw checked exceptions.

[suresh mulagala]

Originally posted by Adam Schaible:
De-compile your code, the compiler adds the throws clause.

I was trying to test this...

class test {
 
public static void main (String[] args){
    go(); // wont compile here
}
private static void go() throws Exception {
     throw new Exception();
}
}

Leave alone de-compiling..the above code doesnt comile in the first place..so whats this thing adding to the main method meant???

[Adam Schaible]

Originally posted by suresh mulagala:


I was trying to test this...

class test {
 
public static void main (String[] args){
    go(); // wont compile here
}
private static void go() throws Exception {
     throw new Exception();
}
}

Leave alone de-compiling..the above code doesnt comile in the first place..so whats this thing adding to the main method meant???

Sorry it's been a long time since I've written a main method.. whoops! the three dots is the var-args syntax that allows you to pass multiple arguments of the same type whithout knowing how many you will have at compile time - just my mistake. it's just:

public class test {

public static void main(String[] args) {
System.out.println("Decompile me");
}
}

[Per Radfe]

Originally posted by Jesper Young:
Anything that extends Throwable (exceptions, errors etc.) can be thrown by your own application with the "throws" keyword. There isn't a special set of exceptions that is thrown only by the JVM or only by the application.

In the Master Exam that comes with K&B, there is a question that says: "Which are most commonly thrown by an application or API developer, as opposed to being thrown by the JVM?"

I�m looking for some kind of rule to determine which exception that is most likely to be thrown by JVM or by application developer (programmatically...)?

[Jesper de Jong]

Originally posted by Adam Schaible:
De-compile your code, the compiler adds the throws clause.

Really? I find that hard to believe. Which decompiler are you using? Maybe your decompiler has a bug.

I compiled this (with JDK 1.6.0_02 on Windows XP):

public class Test {
    public static void main(String[] args) {
        System.out.println("Decompile me!");
    }
}

Then I used the javap tool included with the JDK:

javap Test

And I get this:

Compiled from "Test.java"
public class Test extends java.lang.Object{
    public Test();
    public static void main(java.lang.String[]);
}

There is no "throws Exception" added to the signature of the main method.

[Adam Schaible]

Write code that throws a runtime exception, if it doesn't append it, then javap is doing some reversal. I've never decompiled code that cannot throw an exception, but give it a shot with a runtime exception.

[nico dotti]

Per I'm having the same issue. This post is a couple months old so I don't know if it's helpful for me to reply but...

I can't see a consistent rule that will trigger a 'bell' in my brain as RuntimeExceptions can be both thrown by JVM and Programatically...ergh! However...

Programmatically:

Intuitively, you can sort of figure out that an IllegalArgument or IllegalState is going to occur because the calling code did something some how bad when trying to call an API (another program...hence thrown programmatically!) (ie the caller tries to call next() on a Scanner that's already closed!; The caller tries to setPriority(11) on a Thread and '11' is not a legal argument for setting priority). For NumberFormatException: ie: a NumberFormatException happens because the program tries to parseInt on a literal that could never be an int "32fs__$3"...this is thrown again programmatically because it's an invalid argument to another program (API). AssertionError: ie: if a program tries to assert something that ain't so LOL. Hmm, I guess an assert(boolean) is still an API call, so again it gets thrown programmatically. Ok, so I think that's it for the programmatically thrown exceptions we need to know for the test. If you're using (and trusting as I am) the chart on pg. 370 of the Bates Sierra book, than you can see that there are only 4 listed as Programtically thrown. So I guess remember the above and then the rest are going to be JVM.

Pneumonic maybe? Can't think of a good one though.

BTW, here's some code snippets that exemplify throwing the exceptions/errors from the chart in the B&K book so you don't have to go digging around for examples (note that I really shouldn't be catching some of these exceptions but I wanted to see them all in the console output ):

--------------

   
// Common Exceptions as listed on p. 370 of Sierra book
import java.util.Scanner;
 
class CommonEx {
public static void main (String [] args) {
 
// ArrayIndexOutOfBounds
int [] ia = new int [2];
try {
ia[2] = 123; // ArrayIndexOutOfBounds!
} catch (ArrayIndexOutOfBoundsException obe) {
obe.printStackTrace();
}
 
// ClassCastException
try {
Object o = new Integer(123);
System.out.println( (Byte) o);
} catch (ClassCastException cce) {
cce.printStackTrace();
}

// IllegalArgumentException
try {
Thread.currentThread().setPriority(11);
} catch (IllegalArgumentException iae) {
iae.printStackTrace();
}

// IllegalStateException: this example shows it when
// you try to use the scanner method next() but it's closed!
try {
String input = "1 fish 2 fish red fish blue fish";
Scanner s = new Scanner(input);
    System.out.println(s.next());
    s.close(); 
    System.out.println(s.next());
} catch (IllegalStateException ise) {
ise.printStackTrace();
}

// NullPointerException 
try {
String str = null;
System.out.println( str.length() );// NullPointerException 
} catch (NullPointerException npe) {
npe.printStackTrace();
} 
// NumberFormatException
try {
int j = Integer.parseInt("3er3");
} catch (NumberFormatException nfe) {
nfe.printStackTrace();
}
// AssertionError
// have to start this with -ea to turn 'enable assertions' or
// this will be bypassed (java -ea <prog_name> :wink: 
try {
int x = 3;
assert (x < 2);
} catch (AssertionError ae) {
ae.printStackTrace();
}
}
 
// If SecurityManager is not on ExceptionInInitializerError thrown: 
// Uncomment to see (but this happens at class loading so you won't
// see the other exceptions.
/*
static {
if(System.getSecurityManager() == null)
throw new SecurityException();
}
*/
}
// Class B is in another file. If we compile it, then compile this code,
// everything will be fine. If we delete class B it will throw a
// NoClassDefFoundError
class A extends B {}
 

----------
NoClassDefFoundError Example:

    
public class NoClassDefFoundErrorTest {
public static void main (String [] args) {
A a = new A();
}
}
class A extends B {}
 

[nico dotti]

Oops. The end of the first file should be ignored for the NoClassDefFoundError example use the one that follows. Create a class B {} compile it, then compile the NoClassDefFoundErrorTest, then delete the B.class, then run NoClassDefFoundErrorTest and it will give you the error.

[Kelvin Chenhao Lim]

I'm not a fan of the term "thrown programmatically" as a supposed contrast to "thrown by the JVM". In my opinion, it's much clearer to think of it as "thrown explicitly" (a.k.a. "programmatically") versus "thrown implicitly" (a.k.a. "by the JVM").

Using this terminology, an "explicitly thrown" exception is one that can only be thrown in Java code using a "throws" or "assert" statement, i.e. there must be some expression of programmer intent to (possibly) cause an exception at that point. On the other hand, an "implicitly thrown" exception is one that can occur even in expressions that have neither a "throws" or "assert". Most of these are the result of abruptly completed evaluations, e.g. dereferencing a null reference or an integer division by zero.

Hopefully this way of differentiating exceptions will help some of you. Also, it may be helpful to read what the JLS has to say about the causes of exceptions.