• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

To author : Checked Exception in java

 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Author,

I have a question - Do you think that it would have been better if "Checked" exception were not used in Java i.e.only unchecked exceptions (like in C#). Checked exception cause code bloat and many time the developers ignore the checked exceptions by writing "empty" catch blocks. If I am correct Spring framework believes in "Unchecked" exception.

Thanks. Pradeep
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Pradeep!

There is a lot of buzz about this Checked vs Unchecked Exception stuff outthere. While I cannot say I did a lot of reasoning on this matter, I feel that the correct balance of both is the right way. I can think of a few places where having Checked exception is a good thing (interlayer communication, requiring so to take a decission) and places where Unchecked exception are best fitted (usually i would use them inside a framework - see Spring, Hibernate 3.0).

--
:alex |.::the_mindstorm::.
 
author
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Pradeep,

I'd tend to agree with Alex... the choice of checked vs. unchecked exceptions tends to be governed by the underlying assumptions upon which an API or framework is built. Depending on how rigorously and consistently those assumptions are enforced, it may be acceptable to rely entirely on unchecked exceptions, on checked exceptions, or on a mix of the two.

The rationale behind the checked exception is to communicate to a developer that there is a well-known error condition in an API call. Furthermore, I'd say that such an exception is most appropriate when it represents an error that the developer

  • is aware of
  • can do something about
  • has a choice for how to address the problem (usually)
  • could cause broader code failures if left unaddressed (often)


  • If these conditions are met, it seems reasonable to formally communicate the need to address the error. This would be particularly true (as Alex observed) when working between code layers, especially if the layers wwere independently developed and did NOT have a formal handling infrastructure in place.

    Unchecked exceptions, on the other hand, are useful in cases where the IS such an infrastructure in place to provide an acceptable "safety net" should such an error occur. They also tend to be useful when there are error conditions that have a suitable default recovery action that can be enforced in code should the developer elect to ignore the fault. I personally tend to think that one of the reasons unchecked exceptions are so popular today is due to the more sophisticated enterprise frameworks that have evolved over the lasst few years. If such frameworks are consistent and reasonable in how they handle such error conditions, they can offer a major boon to developers.

    The situations where the development community tends to get itself into trouble is when it uses handling alternatives as a reflex action, decoupled from thought and planning. There is a risk that developers will simply ignore unchecked exxceptions because they don't have to do anything about them. Likewise, there's a risk that developers will opt for the easy solution of a checked exception by "hiding" the source of the error in an empty catch block. Both stem from what I like to call reflex coding; both tend to substantially decrease code maintainability.

    Hope this helps; thanks very much for your question. On a totally unrelated thread, thanks for letting me put the table of contents for "Robust Java" on your blog, Alex.

    Best wishes,
    Steve
     
    Alexandru Popescu
    Ranch Hand
    Posts: 995
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    You are welcome Steve. I have enjoyed the first pages of the book, but unfortunately one of my collegues took the book for quite a while . It would be great if I could ....

    cheers,
    --
    :alex |.::the_mindstorm::.
     
    reply
      Bookmark Topic Watch Topic
    • New Topic