This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Hands On Software Engineering with Python and have Brian Allbey on-line!
See this thread for details.
Win a copy of Hands On Software Engineering with Python this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst

checked versus runtime business/custom exceptions  RSS feed

Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
When building your own exception hierarchy, I see a lot of experts suggesting to make exceptions checked only if the caller can do something about it.
I have a few issues and doubt with that. I feel that in many cases the creator of the class cannot determine whether a exception can be handled by the calling method. For example, if a data fetching method, fetches Zero rows should it throw a checked exception(NoRecordsFoundException) or not. If it does not, then a calling function might not check for that and lead to business-errors in the program.
Also, a DBConnectionFailed exception can be thrown as Checked Exception(DatabaseFetchException).
Thus I feel that Checked exceptions for Business exceptions are more appropriate, as they give the option of calling methods to either re-throw them or handle them (rather than ignoring them). This can lead to more resiliant code, as one should make methods more flexible for future need.
What do others feel on this topic.
- Avianu
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Checked or unchecked. It is, indeed a perienial topic.
My own opinion is that checked is better, except for two kinds of exceptions: those that can't be expected, and those that could occur just about anywhere. So, for example, ZeroDivisionError could occur just about anywhere in a program that does calculations, so it should be unchecked. ArrayIndexOutOfBoundsException could occur just about anywhere, so it should be unchecked. IOException could occur just when you're doing I/O operations, and I'd make it checked (and so would Gosling apparently). And then there are things like OutOfMemoryError -- there's no way it can be expected, so it is unchecked.
Using this reasoning, most "Business" errors are checked. You suggest that you can "re-throw them or handle them", but doesn't require "try { ... } catch(MyException err) { throw err; }" (which I've seen), just document that it's possible by adding "throws MyException" to the method and do nothing in the code. That minor notation is hardly big overhead. A common exception to this rule is exceptions which SHOULDN'T ever happen -- so, for instance, I never write "// should never get here" in my code; I always write "throw RuntimeException("should never get here");" instead (better to die badly than to keep going with invalid data!).
HOWEVER, having said that, the best gurus I've spoken with tend to, as you've suggested, fall into the unchecked-always camp. See for one source. They say that checked exceptions sound great when you're working on a small project, but as soon as things grow to the size of a full-scale project, they start to become a pain. You wind up with a few exceptions that are declared by practically every method as they get passed around. I would say that those ought to be refactored as unchecked when that happens, but I can see their point. So I'm certainly not going to claim that my preferred approach is "best".
-- Michael Chermside
What are your superhero powers? Go ahead and try them on this tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!