Checked Vs. Unchecked Exceptions?

[Shiva.Om Kumar]

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]

Because the people who designed the language decided it would be a good idea.

[Ninad Kulkarni]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

That is the idea, yes.

[Mike Simmons]

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]

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]

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]

"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]

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]

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]

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]

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]

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]

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]

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]

Anyway, nice to see you back, RM.

[Raghavan Muthu]

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]

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

Thank you CR