by jwenting - 2007-06-27 00:42
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...).
by tompalmer - 2007-06-27 21:26
by jwenting - 2007-06-28 00:49
Many checked exceptions (and that's what they were originally intended for) reflect conditions that aren't necessarilly fatal, could possibly be corrected or worked around, probably without the user ever being aware of them. Think of an error being caused by a temporary network glitch, often simply retrying the operation will give the desired result. Or there's an alternate path you can choose. Or a situation where you're processing a batch of data, some of the records in it may fail without crashing the entire run. Cause a checked exception to be thrown at failure and use those to log the failing records which can then be returned to the user. He no longer has to try and potentially fail for each record.
Checked exceptions aren't perfect, that's why there are other mechanisms as well. People who think checked exceptions should be abandoned because they're not perfect are essentially just religious fundamentalists, rooting for something to the exclusion of all else, rather than choosing the best suitable tool for each job at hand.
Sadly that attitude of looking for a Holy Grail, a tool that fits every job perfectly, seems to be rather prevalent among the otherwise usually well educated and intelligent people in this industry.
by tompalmer - 2007-06-28 20:24
by jwenting - 2007-06-29 01:00
by valstadsve - 2007-06-27 07:34
by jwenting - 2007-06-27 22:58
As a result your code becomes more prone to not handling exceptions it can (and should handle) leading to a massive increase in errors causing abnormal program termination (or crashes, as they're also called).
by tompalmer - 2007-06-26 21:57
by hytparadisee - 2007-06-28 06:20
by erickson - 2007-06-27 14:05
by valstadsve - 2007-06-26 05:32
by stridecolossus - 2007-06-26 01:57
by larswestergren - 2007-06-25 00:24
by rickcarson - 2007-06-24 22:31
by stuartcw - 2007-06-24 00:43
by aehrenr - 2007-06-23 06:47
by aehrenr - 2007-06-23 06:43
by datavirtue - 2007-06-23 05:59
by prunge - 2007-06-24 20:53
by bharathch - 2007-06-23 00:06
by kriggio - 2007-06-22 17:54
by jhannes - 2007-06-22 11:10
by mthornton - 2007-06-25 08:10
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.