i am really annoyed by java design, that you have to catch checked (subclasses Throwable). often to relieve client code i am wrapping checked to unchecked (e.g. RuntimeException), which just looks horrible in code. in my opinion only the coder should decide whether he wants to catch an exception or leave it.
does anybody know, if mustang or dolphin are introducing the concept that all exception are unchecked by default?
I find it more annoying that there are unchecked Exceptions which cannot be made checked. If there is a likelihood of an exception, then it is quite right that the Supplier (what you call the Client, presumably) enforce exception handling on the Client. And yes, I do know whether Mustang allows unchecked exceptions by default. It doesn't.
Originally posted by Campbell Ritchie: I find it more annoying that there are unchecked Exceptions which cannot be made checked.
Well you can make unchecked exception as checked exception by wrapping unchecked exception in checked exception and re-throw this newly formed checked exception [ September 10, 2006: Message edited by: Rohit Bhagwat ]
I wouldn't expect any change in existing Exception classes in future Java versions.
There is an interesting debate about whether checked exceptions were ever a good idea. Plenty of other languages get along fine without them. Bruce Eckell's Thinking In Java has a pretty balanced discussion of the pros & cons. His own opinions have drifted from pro-checked to preferring unchecked over the various editions of the book. I haven't heard if he changed this section again in the 4th edition.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Brian Goetz gives a good overview of the discussion here, which also has several good links at the end to other articles.
"I'm not back." - Bill Harding, Twister
Joined: Dec 29, 2005
yes, i agree with this discussion especially with the point that you should use checked exceptions only if the client code (-> code that calls a provided method) could recover from this application error/failure.
and that should be my decision, i.e. means all exceptions should be unchecked by default, of course it makes often sense to catch exceptions but i don't want a framework to dicate me what to catch explicitly. often in my applications it does not makes sense to catch exceptions, because it is more a application error and not an unusual application "incident" which you could recover from (IOException is a good example).
The usage of exception types depends on application. For instance in one of my previous project, the client donot want any exception in method signature, so there is no way for us and created a custom exception which extends from runtime exception. In every catch block of the method, we have wrapped the checked exception into unchecked exception and will be rethrown for the propagation.
More inputs are welcome on usage.
Joined: Jan 29, 2003
and that should be my decision, i.e. means all exceptions should be unchecked by default
Well, that's an opinion, perhaps a perfectly wonderful one, but not one that the language designers held.
As a style experiment I did one app with a rule that no public method declared any exceptions, caught all checked exceptions and wrapped them with unchecked. It worked very well with the particular architecture involved, but I can see how it would not in others.
The checked/unchecked exception issue rides on a flawed premise. Take a look at the Maybe monad in Haskell or look at "continuation passing style" (CPS) which I have attempted to explain before on this forum in "Java speak".
It is not checked exceptions that are flawed. It is not unchecked exceptions that are flawed. It is exceptions (and ultimately imperative programming) that are the flaws.
Edit: grammar [ September 12, 2006: Message edited by: Tony Morris ]