• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Checked Vs. Unchecked Exceptions?

 
Shiva.Om Kumar
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 21111
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because the people who designed the language decided it would be a good idea.
 
Ninad Kulkarni
Ranch Hand
Posts: 802
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Paul Clapham
Sheriff
Posts: 21111
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 10422
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Shiva.Om Kumar
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 10422
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4567
8
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 49361
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 49361
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is the idea, yes.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 49361
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15354
39
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"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
Pie
Posts: 49361
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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".
 
Raghavan Muthu
Ranch Hand
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 49361
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 49361
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anyway, nice to see you back, RM.
 
Raghavan Muthu
Ranch Hand
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Anyway, nice to see you back, RM.


Thank you CR
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic