*
The moose likes Beginning Java and the fly likes Exceptions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Exceptions" Watch "Exceptions" New topic
Author

Exceptions

Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 176
I am having confusion in this topic..

It is said that there are two types of exceptions :
(1)Checked : Those exceptions which are mandatory to handle. Example : All Exceptions (except Run Time Exception)
(2)UnChecked : Those exceptions which are not mandatory to handle . Example : Run Time Exceptions , Errors.

Also, Exceptions & Errors are defined in two categories :
(1) JVM
(2) Programmatic

My Question :: Is it true that JVM are Unchecked exceptions & Programmatic are Checked ones. If i am wrong then how can we correlate 4 of them.

Thanks in Advance
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
Tarun Oohri wrote: . . . Is it true that JVM are Unchecked exceptions & Programmatic are Checked ones. . . .
No.

I suggest you start by reading the Java Tutorials and the Java Language Specification. The latter can be very difficult to read, however. If that doesn’t answer your questions, please come back.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Tarun Oohri wrote:
Also, Exceptions & Errors are defined in two categories :
(1) JVM
(2) Programmatic


I would say that those two categories cover most (but not all) unchecked exceptions, and they do not cover checked exceptions at all. Checked exceptions are for things that, although we don't usually expect them to go wrong, can co wrong at any time, and are not caused by a problem in the JVM (#1) or by buggy code (#2). Things like a disk being full, a file not being present, a network connection dropping. These are what checked exceptions are used for, and they don't fit either of those two categories.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4425
    
    8

Jeff Verdegan wrote:These are what checked exceptions are used for, and they don't fit either of those two categories.


I suspect the topic is inspired by the OCMJP syllabus, and in that context they do. It just makes a distinction between exceptions that are thrown directly by the JVM (like NullPointerException and ArrayIndexOutOfBoundsException) and those that are thrown explicitly by a new XyzException() call (whether in your own code or in a library). It doesn't really tell you anything about why the exceptions are used.

So I suspect most checked exceptions end up being "programmatic" (I can't think of any offhand that aren't), and JVM exceptions are likely to be unchecked. But there are plenty of unchecked ones that are programmatic.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Tarun Oohri wrote:My Question :: Is it true that JVM are Unchecked exceptions & Programmatic are Checked ones. If i am wrong then how can we correlate 4 of them.

At the risk of starting a philosophical discussion, it's worth pointing out that Java is one of the few major languages that makes this distinction at all.

I believe that the original intent was that that checked Exceptions were ones that a program could reasonably be expected to recover from, whereas unchecked Exceptions indicated a genuine error (ie, a program "bug"). However, I think that the distinction has long since been blurred, not least by "catch-all" Exceptions such as IOException and SQLException, which are checked.

The fact is, it exists: A checked Exception must be declared or caught - it's as simple as that. How you deal with them is up to you; and the links you've already been given may help to answer some of those questions.

And I warn you: it's not simple.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Winston Gutkowski wrote:
I believe that the original intent was that that checked Exceptions were ones that a program could reasonably be expected to recover from, whereas unchecked Exceptions indicated a genuine error (ie, a program "bug"). However, I think that the distinction has long since been blurred, not least by "catch-all" Exceptions such as IOException and SQLException, which are checked.

The fact is, it exists: A checked Exception must be declared or caught - it's as simple as that. How you deal with them is up to you; and the links you've already been given may help to answer some of those questions.

And I warn you: it's not simple.


Indeed.

I like the philosophy of checked exceptions. "When I call you, you have to tell me ahead of time exactly what things can go wrong (aside from stuff out of your control like bugs or internal JVM problems), so that I can decide how to deal with it." I like the idea of knowing what to expect. As I'm writing my code to call that method, I know what can go wrong and I can respond to specific problems as appropriate to those individual problems.

In practice, it doesn't usually work out that way.

The vast majority of checked exceptions are handled in one of 3 ways:

1) We just add them to our own throws clause, so that if the method we're calling throws XyzException, we also now throw XyzException.

2) When the list from #1 gets too long, or we're just feeling lazy or know that we won't be handling any checked exceptions, we declare throws Exception. This is a complete end-around of the whole reason for checked exceptions in the first place, and utterly defeats the purpose.

3) We wrap them in something layer-appropriate, and throw that. For example, we might take both SQLExceptions and IOExceptions and wrap them in AccountProcessingException.


With all of the above, we get a bunch of extra code just to mostly say, "yeah, let things continue on as they were going anyway." It adds a lot of clutter and very little value.


There have been only a few times in about 15 years of Java programming that I have actually handled different checked exceptions in a materially different fashion. The last one I remember was several months ago, where I handled SocketTimeoutException (or something like it) specially.

And here's the real kicker: Even though the method you call is required to document what can go wrong, it will almost always do so by a catch-all exception like IOException or SQLException. So it may throw 10 different IOExceptions, but it doesn't have to list them individually. If you want to handle some situation specially, you have to hope the javadocs give you more detail, or else take an educated guess at which specific exception might apply to that situation.


tl;dr: Checked exceptions are a nice idea in theory, but in practice, they don't usually get used in a way that takes advantage of the reason the exist in the first place.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Jeff Verdegan wrote:I like the philosophy of checked exceptions. "When I call you, you have to tell me ahead of time exactly what things can go wrong (aside from stuff out of your control like bugs or internal JVM problems), so that I can decide how to deal with it."

Amen.

Unfortunately, the practice usually falls short of the intent.

@Tarun: One thing I used to do (strictly against the "philosophy" we've been talking about, but an alternative) is to declare my main() methods as:
public static final void main(String[] args) throws IOException, SQLException { ...

which, while not exactly dealing with the "how" that Jeff and I were discussing, at least allows you to call any method (or constructor) that throws either of those horrible Exceptions.

I'm a firm believer in the idea that if a program has an unrecoverable error, you should see its stacktrace exactly as it happened; and the above paradigm at least allows for that.

Winston
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 176
Winston Gutkowski wrote:
Jeff Verdegan wrote:I like the philosophy of checked exceptions. "When I call you, you have to tell me ahead of time exactly what things can go wrong (aside from stuff out of your control like bugs or internal JVM problems), so that I can decide how to deal with it."

Amen.




WoW...Thanks a lot everybody for your guidance ... will go through all once again and will come back to you guys where in doubt ..
Thanks Again!!!
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Tarun Oohri wrote:Thanks Again!!!

You're most welcome.

Happy reading.

Winston
 
 
subject: Exceptions