Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

To Check or Not to Check  RSS feed

 
Guy Reynolds
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know I'm a little late, and perhaps the issue has already been discussed, but I am wondering what others think about an idea that was published in January's Java Report.
Basically, the article's premise was, if you can pull sneaky work arounds with exceptions, like catch( Exception e ) {}, then why catch exceptions at all. The author states "I immediately switched all my exceptions... making their superclass RuntimeException". He further stated "The overall effect of switching to unchecked exceptions was to simplify my code, remove redundancies, and make it log and handle errors more consistently".
what does everyone think about this???
 
John Bateman
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
I'll have to jump back into that issue and refresh myself on the finer points of why he did this. But I remember reading it and pretty much disagreeing with his suggestions to "turn off" exceptions.
Exceptions are there to let you know that something really out of the ordinary went wrong. When you group everthing into a try/catch block like so...

Then you are saying everything that happens out of the ordinary should be treated in the EXACT same why.
This should not be your case.
Let's look at a block of code (or pseudo code) that would make this totally inapproproate to do.

Now if your exception is thrown, how will you fix it or handle it?
- Is the exception being thrown a "ClassNotFoundException" as it cant't find the db driver to load? Maybe you have an alterate driver you want to try loading?
- Is the exception a general "SqlException" because your statement is wrong, your stored procedure can't be found or what?
- Is the exception a "FileNotFoundException" when it tries loading the properties file.
- Or, is the exception and "IoException" because you don't have enough rights to read that file?
Weighing the cost of losing the ability to react to what's going wrong and adding a bit of performance can be a tightrope act, but in my honest opinion I think keeping the detailed information to help easily fix problems as they arise and not start playing a guessing game is much more worth it in the end.
Using another adage, you CAN build a house without a blueprint (most wouldn't) but who would you blame when/IF the thing crashed on your head?
Hopefully not me!

P.S. sorry I didn't touch on it specifically, but making "ALL" your exceptions runtime just makes it possible to write even worse code (IMHO) as developers who may not be familiar with your API or set of classes won't even know that an exception can be thrown unless they know the API inside out. Making them 'compiletime' reminds them something crazy may happen at a certain point in time. This works nice as they can take action before it does.
------------------
SOURCE CODE should be SURROUNDED by "code" tags.
Click here for an example
[This message has been edited by John Bateman (edited July 05, 2001).]
 
Guy Reynolds
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks,
I agree. The runtime exceptions seem appealing because you could let everything bubble up, group like exceptions and handle them in consistent and appropriates ways, but it seems like code re-use would suffer.
maybe it's worth a test though...
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!