Java exceptions don't have to be useless!Bill de hÓra has started a very interesting thread in Exceptions considered pointless. Bill says:
Three rules of thumb are forming in my mind around exceptions:
- don't swallow exceptions (with two exceptions)
- avoid using exceptions
- avoid inventing exceptions
The first many Java developers will understand. Rarely, you know an exception is not going to be thrown, but you have to catch it anyway, and sometimes you have to catch InterruptedException as part of normal program flow.
The last two are maybe controversial.
Although I understand where this feeling comes from, I disagree with the whole darned concept. Exceptions are one of the more powerful and well done refinements that C++ introduced to C. They allow us to enforce the idiom of one entry point, one return point unless things go badly wrong. When done well, they also allow method level determinism of what can and can not be dealt with, and for more advanced applications, turning a problem into a solution.
I agree completely with the comments by Bob McWhirter, where he says:
I truly think that the idiom of using String messages as parameters for an exception and the getMessage() method have contributed to the uselessness of many exceptions.
This is same darned problem people still have in the C++ world, and most of them have never figured it out. String based exceptions are completely useless unless you employ parsers at every level of the application (and they make internationalization nearly impossible). Java has further contributed to the problem by making exceptions have some sort of context (a stack trace for example) but has not allowed developers to easily construct one exception type from another and retain that context. Inexperienced (and seasoned) developers alike are liable to create new exception types at the drop of hat for reasons I've never been able to fathom.
Our solution to this problem has been a complex exception type (that builds its getMessage() string based on internal data, whatever that might be). We also override printStackTrace(), so that we can capture the original stack trace of the primary exception (when an exception is created from another exception). There is some overhead associated with this that we'd like to avoid, namely capturing stack trace data that we may not use, but as it turns out, we nearly always use it because getMessage() sticks the first line of the stack trace onto the end of the message data; and the nice thing is that we capture the data the first time we need it, minimizing the impact the next time around. My understanding is that 1.4.1 solves this particular problem, we shall have to see.
All of our exceptions (in one current 60K+ line application, we have three exception variants) descend from the complex exception. Unlike your typical Java application which has catch blocks from hell (or just passes on everything), we have the ability to make judgments based on the exception type (generally, we only catch one or two types at a given module level) and the semantic data within. Which leads to ...
Swallowing exceptions is not unusual at all. Consider anything which implements a try/catch/finally block. I certainly hope that you swallow all exceptions in the finally block, or else the original exception is going to get lost in the noise. Also, if you throw away rules of thumb two and three, you are going to have normal operations (hopefully rare), in which an exception is simply a way of communicating a normal error condition, so you'll swallow it and try something else based on the context information in the exception.
The single biggest problem with rich exceptions is that everything starts to bubble into them. You need to be careful to keep things well defined and when exceptions become too complicated, factor them back into an inheritance tree that everyone can live with.
1:58:04 AM 
|
