• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Runtime Exceptions

 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Stephen,

What is your take on the use of runtime exceptions vs checked exceptions?
Folks seem to be favoring using runtime exceptions for everything that is unexpected / unrecoverable & only using checked exceptions where the exception in effect represents a return value.
What does a Sun rep. say?

Cheers,
Louise
 
author
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Louise,

Based on a number of years spent in Java training, I'll fall back on the tried and true reply - "it depends".

Ok, now on to a more useful, semi-serious answer!

The runtime exception has had a somewhat contentious history in the Java language, as you probably know. Because the handling of errors tends to be strongly tied to developer philosophy, it's a topic of very... lively... debate.

RuntimeException was originally used in the Java APIs to identify what could broadly be classified as "avoidable coding problems". In other words, most of the RuntimeException subclasses could be avoided entirely with a bit of coding. One example: developers can avoid the infamous NullPointerException if they check to see if the object reference is not null. Another: the IllegalArgumentException, which developers can avoid by prequalifying their input to method calls.

As unchecked exceptions, RuntimeExceptions do not require developers to follow the process of handling or declaring them. The reason for this is fairly pragmatic: it is unrealistic to expect developers to address every possible failure scenario due to this type of problem. If you had to handle or declare every possible case where you could get a NullPointerException, your code would end up as a big try-catch block!

As Java has expanded into the enterprise realm, the advent of architectural frameworks has encouraged the unchecked exceptions to be used in a somehwat new context. Specifically, unchecked exceptions tend to be used in enterprise servers to represent unexpected, "platform-related" errors. This trend manifests itself in J2EE as well as the more recent lightweight enterprise frameworks such as Rod Johnson's Spring. This is practical in part to the fact that the enterprise servers have a standardized handling infrastructure. Such frameworks have infrastructure to intercept and deal with this category or error, so developers can effectively leverage unchecked exceptions without danger of destabilizing an application.

Which is more appropriate... the checked or the unchecked exception? I'd still tend to assert that "it depends" on the goals of a development team, combined with the degree to which they have a standardized handling strategy within their application environment. Used effectively, the unchecked exception can be an enormously useful addition to a team's handling repertoire. If misused, it can pose a major threat to application stability.

Hopefully I've provided a detailed (and diplomatic) enough answer. Thanks very much for the question, Louise!
reply
    Bookmark Topic Watch Topic
  • New Topic