File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Checked Vs. Unchecked Exceptions? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Checked Vs. Unchecked Exceptions?" Watch "Checked Vs. Unchecked Exceptions?" New topic
Author

Checked Vs. Unchecked Exceptions?

Shiva.Om Kumar
Ranch Hand

Joined: Jun 14, 2010
Posts: 68
There are two kind of Exceptions:

1. Checked - must be catch (or throw) and extended from Exception .e.g. SQLException
2. Unchecked - not mandatory to catch at compile time and extended from RuntimeException .e.g. NumberformatException

If I am writing a code & I suspect a NumberformatException, then I will have a catch block for NFE
If I am executing a SQL & I (mandatory) need to have catch SQLException

Why we have two kind of Exceptions (checked & unchecked); in both cases above, if I wish to handle both kind of Exceptions, I need a catch blocks.
Why don't we have just (only) unchecked exceptions? To prevent NFE, if I am having catch for it then I would do same for SQL handling too, why Java has mandatory to catch it?


Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18887
    
    8

Because the people who designed the language decided it would be a good idea.
Ninad Kulkarni
Ranch Hand

Joined: Aug 31, 2007
Posts: 802

If code is behaving unexpectedly we can identify root cause of problem by using exception.
Handling of Checked as well as Unchecked exceptions are totally depends on design.


SCJP 5.0 - JavaRanch FAQ - Java Beginners FAQ - SCJP FAQ - SCJP Mock Tests - Tutorial - JavaSE7 - JavaEE6 -Generics FAQ - JLS - JVM Spec - Java FAQs - Smart Questions
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18887
    
    8

Paul Clapham wrote:Because the people who designed the language decided it would be a good idea.

Seriously, that's the answer to pretty much every question of the form "Why does feature X exist (or fail to exist) in Java?" The designers didn't publish a detailed architectural document explaining why they made the decisions they made. However, if you want to discuss why it might be a good idea, or a bad idea, or you want to ask a question about how it works, then do go ahead and ask such a question.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8196
    
  23

Shiva.Om Kumar wrote:To prevent NFE, if I am having catch for it then I would do same for SQL handling too, why Java has mandatory to catch it?

It doesn't. It just requires that if you don't catch it, the method declares that it might be thrown.

However, it tends to suggest that it might not be a bad idea to use a try...catch block. Do you have any particular objection to them?

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Shiva.Om Kumar
Ranch Hand

Joined: Jun 14, 2010
Posts: 68
Paul Clapham wrote:
Paul Clapham wrote:Because the people who designed the language decided it would be a good idea.

Seriously, that's the answer to pretty much every question of the form "Why does feature X exist (or fail to exist) in Java?" The designers didn't publish a detailed architectural document explaining why they made the decisions they made. However, if you want to discuss why it might be a good idea, or a bad idea, or you want to ask a question about how it works, then do go ahead and ask such a question.


Thanks for replying & guiding on this issue.

Earlier I didn't intend to raise why such feature is there (or not).

My intention is to understand the reason for having two separate kind of Exceptions;
is there any benefit of one kind over other?
SQLException may or may not occur but we (are forced to) catch
NumberformateException may or may not occur on conversion of user input (not forced)

(again repetitive question sorry)... :rolleyes:
Shiva.Om Kumar
Ranch Hand

Joined: Jun 14, 2010
Posts: 68
Winston Gutkowski wrote:
Shiva.Om Kumar wrote:To prevent NFE, if I am having catch for it then I would do same for SQL handling too, why Java has mandatory to catch it?

It doesn't. It just requires that if you don't catch it, the method declares that it might be thrown.

However, it tends to suggest that it might not be a bad idea to use a try...catch block. Do you have any particular objection to them?

Winston


I don't have any objection...
I intend to understand why for one kind of Exception (SQLE) one need to (mandatory) catch or use throws
but for other (NFE) one can code without using catch / throws
Shiva.Om Kumar
Ranch Hand

Joined: Jun 14, 2010
Posts: 68
Ninad Kulkarni wrote:If code is behaving unexpectedly we can identify root cause of problem by using exception.
Handling of Checked as well as Unchecked exceptions are totally depends on design.


Can you please share example or a case where using checked or unchecked exception matters?
Why SQLE is mandatory to catch or throws - process may / may not encounter exception
Why NFE is not mandatory to catch or throws - process may / may not encounter exception


Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8196
    
  23

Shiva.Om Kumar wrote:I don't have any objection...
I intend to understand why for one kind of Exception (SQLE) one need to (mandatory) catch or use throws
but for other (NFE) one can code without using catch / throws

Well, one reason is that the designer of the method decided that you may regard the error as recoverable. In those cases, it will usually throw a checked Exception, hopefully prompting you to use a try..catch block and take the necessary recovery steps if they are possible.

In the case of something like NFE, there's really nothing much you can do: The format is wrong and it's a bug; and you need to correct it. Therefore, it throws an unchecked Exception, which is more likely to result in a program error.

However, it's not the only reason, by any means.

Winston
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4461
    
    8

The general distinction (and there are some examples which don't quite follow this rule) is that checked exceptions are for things that aren't under the programmer's control, and so they might happen under normal use and your program ought to cope with it. Whereas unchecked exceptions are things that are under the programmers control, and can only happen if there's a bug in the code.

For example, you should always be able to prevent a null-pointer exception (by not calling methods on references that can be null without checking them first). But if you're trying to connect to a database then you can't always guarantee it'll be sucessful (the server might be down, for example).
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39791
    
  28
A runtime Exception is one which occurs entirely inside the runtime system, and other Exceptions are caused by occurrences outside the runtime. So a non-runtime Exception is something the program ought to try to recover from.
Shiva.Om Kumar
Ranch Hand

Joined: Jun 14, 2010
Posts: 68
Thank you all,

I believe I got the idea, unchecked exceptions can be prevented like NullpointerE (by checking if object reference is null or not) & NumberformatException (validating user input before conversion)

But SQLE can't be prevented in some cases.


thank you very much for helping me.....
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39791
    
  28
That is the idea, yes.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Campbell Ritchie wrote:A runtime Exception is one which occurs entirely inside the runtime system, and other Exceptions are caused by occurrences outside the runtime.

Hm, I don't think I agree with this. But it's hard to even tell what it means, really. I would say that all exceptions (and Errors and other Throwables) occur entirely inside the runtime. Their cause may well be outside the runtime, or not, but you can't consistently determine that from whether it's a RuntimeException or not. I would further add that the name RuntimeException is an extremely crappy and useless name, in my opinion, as it has no real correlation with what it means. I would agree with most of the other recent posts, however. Perhaps I am missing something about what you mean here - can you give some examples?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39791
    
  28
The Java Tutorials say
internal to the application
so I believed it, but I have know the tutorials to be mistaken elsewhere.

But I agree, RuntimeException is a misleading class name.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14338
    
  22

This page from Oracle's Java Tutorials gives some information:

The Java Tutorials wrote:
The Three Kinds of Exceptions

The first kind of exception is the checked exception. These are exceptional conditions that a well-written application should anticipate and recover from. For example, suppose an application prompts a user for an input file name, then opens the file by passing the name to the constructor for java.io.FileReader. Normally, the user provides the name of an existing, readable file, so the construction of the FileReader object succeeds, and the execution of the application proceeds normally. But sometimes the user supplies the name of a nonexistent file, and the constructor throws java.io.FileNotFoundException. A well-written program will catch this exception and notify the user of the mistake, possibly prompting for a corrected file name.

Checked exceptions are subject to the Catch or Specify Requirement. All exceptions are checked exceptions, except for those indicated by Error, RuntimeException, and their subclasses.

The second kind of exception is the error. These are exceptional conditions that are external to the application, and that the application usually cannot anticipate or recover from. For example, suppose that an application successfully opens a file for input, but is unable to read the file because of a hardware or system malfunction. The unsuccessful read will throw java.io.IOError. An application might choose to catch this exception, in order to notify the user of the problem — but it also might make sense for the program to print a stack trace and exit.

Errors are not subject to the Catch or Specify Requirement. Errors are those exceptions indicated by Error and its subclasses.

The third kind of exception is the runtime exception. These are exceptional conditions that are internal to the application, and that the application usually cannot anticipate or recover from. These usually indicate programming bugs, such as logic errors or improper use of an API. For example, consider the application described previously that passes a file name to the constructor for FileReader. If a logic error causes a null to be passed to the constructor, the constructor will throw NullPointerException. The application can catch this exception, but it probably makes more sense to eliminate the bug that caused the exception to occur.

Runtime exceptions are not subject to the Catch or Specify Requirement. Runtime exceptions are those indicated by RuntimeException and its subclasses.

Errors and runtime exceptions are collectively known as unchecked exceptions.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
"Internal to the application" (as opposed to the runtime) makes sense to me as a description for the apparent intended use of runtime exceptions. There are various places where this guideline is violated, especially nowadays when whole frameworks like Spring and Hibernate make most everything into a runtime exception. But I agree it's how Sun apparently wanted them to be used, most of the time.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39791
    
  28
Mike Simmons wrote:. . . There are various places where this guideline is violated, . . .
Isn’t it quicker to enumerate the places where guidelines aren’t violated?
Raghavan Muthu
Ranch Hand

Joined: Apr 20, 2006
Posts: 3355

Mike Simmons wrote: I would further add that the name RuntimeException is an extremely crappy and useless name, in my opinion, as it has no real correlation with what it means. I would agree with most of the other recent posts, however. Perhaps I am missing something about what you mean here - can you give some examples?


To me it makes a clear sense when I look at the definition of the terms , "Compile time exception" Vs "Runtime Exception".


Everything has got its own deadline including one's EGO!
[CodeBarn] [Java Concepts-easily] [Corey's articles] [SCJP-SUN] [Servlet Examples] [Java Beginners FAQ] [Sun-Java Tutorials] [Java Coding Guidelines]
Raghavan Muthu
Ranch Hand

Joined: Apr 20, 2006
Posts: 3355

Mike Simmons wrote: There are various places where this guideline is violated, especially nowadays when whole frameworks like Spring and Hibernate make most everything into a runtime exception. But I agree it's how Sun apparently wanted them to be used, most of the time.


Yes, I agree with it. Not just Spring, Hibernate like frameworks , I have seen few other custom application frameworks abusing Runtime exception as nowhere you can see a single checked exception! Whenever I wear a developer hat, I feel like brutally killing those people for this blatant sin!

It is because I never know what kinda exception would be thrown by the method I invoke, which is present inside a Jar file. Only at runtime I may come to know and I needed to do this reverse engineering to just find out a specific exception, which was my requirement at once!
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39791
    
  28
Raghavan Muthu wrote:. . . brutally killing those people for this blatant sin! . . .
Don’t do that. Maybe they will suffer worse if they are just alive!
Raghavan Muthu
Ranch Hand

Joined: Apr 20, 2006
Posts: 3355

Campbell Ritchie wrote:
Raghavan Muthu wrote:. . . brutally killing those people for this blatant sin! . . .
Don’t do that. Maybe they will suffer worse if they are just alive!


what do CR? All what I can do is to just express my feelings like this through words! Even If I wanted to do something really, they were not available in person. Their good luck

On a off-track note, I believe you had been doing well these days. Its been quite a long time I could visit JR/CR (JavaRanch/CodeRanch)! I missed it very much!
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Raghavan Muthu wrote:
Mike Simmons wrote: I would further add that the name RuntimeException is an extremely crappy and useless name, in my opinion, as it has no real correlation with what it means. I would agree with most of the other recent posts, however. Perhaps I am missing something about what you mean here - can you give some examples?


To me it makes a clear sense when I look at the definition of the terms , "Compile time exception" Vs "Runtime Exception".

Except that all Exceptions, Errors, and other Throwables occur at run time, not compile time.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Raghavan Muthu wrote:Not just Spring, Hibernate like frameworks , I have seen few other custom application frameworks abusing Runtime exception as nowhere you can see a single checked exception!


Yay!

Raghavan Muthu wrote:Whenever I wear a developer hat, I feel like brutally killing those people for this blatant sin!

And I feel like celebrating them for getting rid of a bad, poorly-implemented idea.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39791
    
  28
Anyway, nice to see you back, RM.
Raghavan Muthu
Ranch Hand

Joined: Apr 20, 2006
Posts: 3355

Mike Simmons wrote:
Raghavan Muthu wrote:Not just Spring, Hibernate like frameworks , I have seen few other custom application frameworks abusing Runtime exception as nowhere you can see a single checked exception!


Yay!

Raghavan Muthu wrote:Whenever I wear a developer hat, I feel like brutally killing those people for this blatant sin!

And I feel like celebrating them for getting rid of a bad, poorly-implemented idea.


Totally different extremes we both are! :P
Raghavan Muthu
Ranch Hand

Joined: Apr 20, 2006
Posts: 3355

Campbell Ritchie wrote:Anyway, nice to see you back, RM.


Thank you CR
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Checked Vs. Unchecked Exceptions?