The Source for Java Technology Collaboration
User: Password:



Start New Message Post a Reply

Subject:  RTFM
Date:  2007-06-27 00:42:39
From:  jwenting
Response to: RTFM


So instead of checking for failure we should just let everything bubble up and bite the user in the face? Great, everything that can go wrong and could be handled now causes "abnormal program termination".

Maybe some things that are checked exceptions shouldn't be, just as some things that aren't should be. A CloneNotSupportedException might be better off as an unchecked exception, but that would depend on the scenario where it's used (in most cases it would indeed indicate a program error and thus should come to bite you, but not always, maybe you want to handle it gently by logging it and providing a nice error message before moving on without the clone in say a plugin system). But a MalformedURLException should be checked. It's almost exclusively due to faulty user input, and should be handled through notifying the user which will often mean he can correct it without having the application crash.

Seems you are one of those people who need to be educated on the correct use of different exception classes...

Spring seems nice only because it deals with exceptions the only way it can, by throwing them up to the user (which will be another application) to deal with, often wrapping them in unchecked exceptions for good measure. Makes handling and dealing with problems in code that uses Spring a lot harder than it could be, as there's often no indication that something's going wrong and where except by digging through multipage stacktraces after your application crashes again because something somewhere went wrong. Spring itself may be reliable when it comes to exception handling because it does nothing but pass on the responsibility to someone else, but that's its job and no proof that doing away with exception handling altogether is a good idea.

Experience has taught me that not handling exceptions (which using unchecked exceptions exclusively implies) makes code less reliable, harder to write and maintain (you'll never know an exception can happen somewhere because there's no indication of it...), and often less readable and even more error prone if you do try to handle them (just catch Throwable, log it maybe, and move on as if nothing happened...).


 Feed java.net RSS Feeds