• Post Reply Bookmark Topic Watch Topic
  • New Topic

Checked Exception is BAD ?  RSS feed

 
Ranch Hand
Posts: 198
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most of the developers and designers are interested to have a unchecked Exception , rather than a checked Exception ?

May i know what the checked Exception is bad about ?
 
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Main reason: Checked exceptions clutter code.
Code becomes messier with too many try/catch blocks. The kind of code into these catch blocks - do nothing valuable: logging the exception and throwing back to the caller. This adds more clutter.

Sometimes exception handling (checked or unchecked) seems to be useful to try execute alternate flow; but again; this decision should be left to the developer than enforced by the API. If required, the developer can catch the exception and handle the alternate scenarios.

Newer languages like Ruby etc avoid checked exceptions.
 
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell's rule of Exceptions no 1: The number of different opinions obtained is equal to the number of people asked.
The "official" line is in the Java� Tutorials: look for "the controversy." By insisting some exceptions be handled, the compiler improves the robustness of the application.

But of course, every language does it differently!
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did you really say exceptions are useful for controlling flow? The simpler techniques with "if-else" are far better for controlling flow.
 
Rajah Nagur
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Campbell Ritchie:
Did you really say exceptions are useful for controlling flow? The simpler techniques with "if-else" are far better for controlling flow.


Misunderstood. By alternate flow - I meant the "exceptional" flow!

Readability of the code improves when the exceptional code is in the exceptional block.
Handling exceptional kind of code using if-else can be misleading.

Exceptional handling can be very tricky. I have see many lazy programmers who just "swallow" the so called checked exeptions i.e. only empty catch blocks and spends hours of futile effort on the test/production server trying to debug the issue.
 
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Checked exceptions have their uses but most of the time unchecked exceptions will be used.

If you have a recoverable condition or need to force the developer to do something when an exception occurs then use checked exceptions. i.e. If accessing a database and an exception occurs then the developer should be forced to at least think about cleaning up the open connection(s).
 
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have a recoverable condition or need to force the developer to do something when an exception occurs then use checked exceptions. i.e. If accessing a database and an exception occurs then the developer should be forced to at least think about cleaning up the open connection(s).


I just thought we should see that again
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I read the article that Campbell Ritchie posted, and I'm in agreement, for the most part, however, I'm torn because at the end it said

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

I'm not sure if I totally agree. Most of the built-in unchecked exceptions are checkable by code, and the client can recover, so that doesn't agree with the Java core language. When I teach this to people, I usually say if an exception can be caught through logic (i.e. preventable), it should be an unchecked exception, if it can't (i.e. unpreventable), it should be a checked exception (e.g. opening a file for reading, since the program is generally on a multi-user platform, it's impossible to determine if the file is there to read, someone may have moved it while your program is running, however, a nullpointer, or divisionbyzero, both of them can be prevented through logic). This is in agreement with the Java core.

If there is a completely unrecoverable problem, it should be an Error, not an Exception.

Just my 2 cents

Garrett
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!