• Post Reply Bookmark Topic Watch Topic
  • New Topic

Unchecked Exceptions  RSS feed

 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

Source:
Unchecked Exceptions — The Controversy, Sun

What does this mean in practice?

Suppose you're DAO class throws a Runtime exception, how do you handle this? What do you present to the end user?
 
Sona Patel
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need to log the exception and can show some error message to end user. Find the cause of exception from log and fix it.

hope it helps...

Regards...
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sona Patel wrote:You need to log the exception and can show some error message to end user.


Is this not the same as catching a checked exception ?
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Checked Exception : when you feel you need to inform to the user(who is using your method) that "this may happen please handle the situation". in this case you throws Checked Exception

Unchecked Exception : known as Runtime Exception . you need to throw when your logic fails . and then catch it and show the error to the client . used with throw key word .

Note : Nowadays programmer advised to throw unchecked Exception over Checked Exception.

Hope this helps
 
Aurelian Tutuianu
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
you should think the catching exception problem on different levels.
You application at some point in execution time have a domain of visibility. It's the stack.
As an example you can have for an hypothetical application something like:

1. Application is running the main thread
2. The form with list of clients is shown
3. The dialog for editing a client is shown
4. The save button is pushed, save method is executing
5. In save method try to create a connection, we are inside a library now

So, this levels on stack can be thought as business relevance levels.
At every level a problem looks different.

In the previous sample if on the 5. level the connection is broken you have:
- for 5th level inside creating connection method is throwed a Runtime connection because from that domain the scope is to create a connection, but because of something this is impossible. So, is a runtime exception because nothing can be done to repair this at this level.
- for the 4th level the same problem looks different. It is true that I tried to save the client information and I couldn't, but I did not lose client information. I can simply announce the user with a message box that I couldn't save. If he wants, he can try again or abort to modify client.

The main point is that at different levels you should reevaluate the problem and give usually a different meaning.

In your particular case I would catch the RuntimeException and transform that in a checked Exception.
Like at 4th level I would catch RuntimeException.
Hope it helps.
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
seetharaman venkatasamy wrote:
Unchecked Exception : known as Runtime Exception . you need to throw when your logic fails . and then catch it and show the error to the client . used with throw key word .

Note : Nowadays programmer advised to throw unchecked Exception over Checked Exception.


Yes, but is this part i try to understand!! I understand what theoretically the difference is between these two kind of exceptions. But what does it mean in practice?

If you write for example some DAO class how does one type of exception make your code better/clearer compared to the other.

Or is it pure an academic discussion?
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Not Sure]Shortly , if you are not working in API [which is used by other programmer mostly]. then try to avoid checked exception
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think there is no exact "science" as to when you should choose a checked exception and when you should choose an unchecked exception. It's more a matter of style and the opinion of the developer.

Some people think that you shouldn't use checked exceptions at all - checked exceptions are a feature unique to Java (other languages do have exceptions, but no check by the compiler as in Java), and some people think it's a failed experiment. Other people think checked exceptions are good, because they provide safety - the user of an API with checked exceptions is forced to think about handling the exceptions.

I think Sun's guideline is good, but it's hard to say exactly what it means in practice. It's up to the programmer. Using checked exceptions means you force the users of your API to think about error handling, but it might also mean that you're forcing them to handle errors about which they couldn't do anything useful.

One problem that can happen with checked exceptions is the following. Suppose you're writing a library or a module for a larger program that uses some library X, and library X throws its own checked exceptions. You're now either forced to handle the exceptions from library X in your library or module, or throw them higher up to the users of your library or module. But if you throw exceptions from library X up to your clients, then you're exposing to your clients that you're using library X in your library or module. You don't want that, because the fact that you're using library X is really an implementation detail of your library or module, that shouldn't be exposed to the outside. It forces clients of your code to understand what library X is and what its exceptions mean. One way to get around this problem is by catching the exceptions of library X in your code, wrapping them in your own (checked or unchecked) exceptions and throwing them further.
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aurelian Tutuianu wrote:You should think the catching exception problem on different levels.
In your particular case I would catch the RuntimeException and transform that in a checked Exception.
Like at 4th level I would catch RuntimeException.
Hope it helps.


But what would it differ if the DAO class had thrown a checked Exception in the first place?
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper Young wrote:You don't want that, because the fact that you're using library X is really an implementation detail of your library or module, that shouldn't be exposed to the outside.


Don't you have the same problem when you use unchecked exceptions?
 
Aurelian Tutuianu
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper Young wrote:One way to get around this problem is by catching the exceptions of library X in your code, wrapping them in your own (checked or unchecked) exceptions and throwing them further.

This is the most common situation and your solution is the normal one. Other ways are exceptions.

But what would it differ if the DAO class had thrown a checked Exception in the first place?

The only difference is that you MUST catch exception if is a checked one.

Even if the biggest API implementation providers make mistakes. This is why is good in Java to transform from an unchecked to checked exception.

There are two aspects regarding unchecked exceptions:
- unchecked exceptions can pollute code too much and it would be a hell to catch everything (performance and legibility)
- unchecked exceptions are usually (not every time) unrecoverable

For a specific situation THE PROGRAMMER must consider if an unchecked exception is recoverable even if is not considered in this way.

Finally there are no clear rules, every time you should fit that behavior to your business.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis Zandvliet wrote:
Jesper Young wrote:You don't want that, because the fact that you're using library X is really an implementation detail of your library or module, that shouldn't be exposed to the outside.


Don't you have the same problem when you use unchecked exceptions?

No, because the client of your code isn't required to catch or re-throw the exceptions from library X in that case.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aurelian Tutuianu wrote:Even if the biggest API implementation providers make mistakes. This is why is good in Java to transform from an unchecked to checked exception.

There are two aspects regarding unchecked exceptions:
- unchecked exceptions can pollute code too much and it would be a hell to catch everything (performance and legibility)

It looks like you have reversed the words "checked" and "unchecked" here.
 
Aurelian Tutuianu
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aurelian Tutuianu wrote:Even if the biggest API implementation providers make mistakes. This is why is good in Java to transform from an unchecked to checked exception.

I consider here a mistake for a db library to throw an unchecked exception. If you can't make connection must be always verified. So here unchecked is used fine.

Aurelian Tutuianu wrote:There are two aspects regarding unchecked exceptions:
- unchecked exceptions can pollute code too much and it would be a hell to catch everything (performance and legibility)

Here a made a mistake. I wanted to write: If all unchecked exceptions would be checked exceptions, that can pollute the code ....

Sorry for that.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!