• Post Reply Bookmark Topic Watch Topic
  • New Topic

Try block bad, catch block good  RSS feed

 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Strange subject I know. Although this question uses database access as an example it really has nothing to do with that and all to do with exceptions.

In a Data Access Object I search for an object by name. Here is the method:



In the above code I throw my own ObjectNotFoundException if looking up this item returns nothing. The interesting part that has everything to do with this post is that returning nothing is not always a bad thing. Sometimes I just need to know that it didn't find an object. For example, when I am adding a new object I don't want to add something that is already there. See the code below:



Notice now that in my try/catch block I actually do the "good" thing if I catch an ObjectNotFoundException. Usually when we think of Exeptions, or at least when I think of Exceptions, I think of the catch block being error reporting. In this case however, if the ObjectNotFoundException is not thrown that is a bad thing.

Is this acceptable practice? Is it ok to do good things when an exception is thrown? Should I be doing this another way?

Thanks.
Notice that
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would argue that MonitorDAO class is simply missing a needed method:



If the queryForObject method caches objects, then you could use this to rewrite your problem code for a net gain in performance. Throwing and catching an exception is still a very expensive operation.

I have indeed written code where the catch block contains non-error-recovery code, and sometimes that's just fine. But I don't think this is one of those cases.

The example that I can recall from my own work is trying to find a class from a series of different class loaders. You keep getting ClassNotFoundExceptions, and you then just try the next one. You're forced to do this because ClassLoader doesn't have a "isAnExistingClass() method.

[ EJFH: Fixed my "code" tags. ]
[ January 12, 2005: Message edited by: Ernest Friedman-Hill ]
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ernest. That is a lot cleaner too.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Specific to your example, in my framework DAO I have provided two versions of each basic query: findByFoo() and getByFoo(). Find() returns null if no object is found while get() throws NoObjectForYouException. I did this specifically to avoid throwing exceptions for cases that aren't really errors as it both clutters up the client code and is a performance drain (is it still really that significant?).

As the DAO is generic (it deals with Entity rather than User, Monitor, etc), this code is all in one place and nicely documented so no one gets confused.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!