aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Exceptions thrown programatically or by JVM? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Exceptions thrown programatically or by JVM?" Watch "Exceptions thrown programatically or by JVM?" New topic
Author

Exceptions thrown programatically or by JVM?

Per Radfe
Greenhorn

Joined: Jul 05, 2007
Posts: 14
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
Ranch Hand

Joined: Jul 23, 2007
Posts: 203
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)


http://subodh-gupta.blogspot.com
suresh mulagala
Ranch Hand

Joined: Feb 18, 2003
Posts: 41
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
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13875
    
  10

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.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Adam Schaible
Ranch Hand

Joined: Oct 04, 2007
Posts: 101
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
Ranch Hand

Joined: Apr 22, 2006
Posts: 424
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
Ranch Hand

Joined: Feb 18, 2003
Posts: 41
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
Ranch Hand

Joined: Oct 04, 2007
Posts: 101
De-compile your code, the compiler adds the throws clause.
ahmed yehia
Ranch Hand

Joined: Apr 22, 2006
Posts: 424
If the Compiler do that, then it wouldnt require me to handle code that may throw checked exceptions.
suresh mulagala
Ranch Hand

Joined: Feb 18, 2003
Posts: 41
Originally posted by Adam Schaible:
De-compile your code, the compiler adds the throws clause.


I was trying to test this...


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
Ranch Hand

Joined: Oct 04, 2007
Posts: 101
Originally posted by suresh mulagala:


I was trying to test this...


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
Greenhorn

Joined: Jul 05, 2007
Posts: 14
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
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13875
    
  10

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):

Then I used the javap tool included with the JDK:

javap Test

And I get this:

There is no "throws Exception" added to the signature of the main method.
Adam Schaible
Ranch Hand

Joined: Oct 04, 2007
Posts: 101
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
Ranch Hand

Joined: Oct 09, 2007
Posts: 124
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 ):

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



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


nico dotti
Ranch Hand

Joined: Oct 09, 2007
Posts: 124
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
Ranch Hand

Joined: Oct 20, 2007
Posts: 513
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.


SCJP 5.0
 
 
subject: Exceptions thrown programatically or by JVM?
 
Similar Threads
Exception types
Exception being thrown by JVM / Programmatically
AssertionError clarification
Programmatically or JVM thrown Exception?
Assertion Error