 Catching Uncaught Exceptions in JDK 1.5
started 5/30/2004; 2:13:29 AM - last post 5/31/2004; 11:59:02 AM
|
|
Dan Shappir - Catching Uncaught Exceptions in JDK 1.5 
5/30/2004; 2:13:29 AM (reads: 11785, responses: 6)
|
|
| Catching Uncaught Exceptions in JDK 1.5 |
|
In my experience, all Java projects contain poorly written exception handling code.
An interesting article on exception handling and finalization in Java.
Frequently, exceptions are stubbed out and ignored, because the writer of the code did not know how to handle the error (and was going to go back and fix it, one day, but the project manager was breathing down his neck and the release had to go out that afternoon). This is bad, since you then do not know that something has gone awry. On the other hand, if the exception bubbles up the call stack, it may kill the thread, and you may never know that there was an exception.
Looks like an interesting resource, especially if you use Java.
Posted to Software-Eng by Dan Shappir on 5/30/04; 2:15:07 AM
|
|
|
|
bryan rasmussen - Re: Catching Uncaught Exceptions in JDK 1.5
5/31/2004; 8:17:10 AM (reads: 320, responses: 1)
|
|
|
Isn't that the case with most languages used in professional development? I don't know if it's the fault of the need to get a product out, or the languages themselves, but I seldomly see any decent error handling.
|
|
Ehud Lamm - Re: Catching Uncaught Exceptions in JDK 1.5
5/31/2004; 8:19:58 AM (reads: 319, responses: 0)
|
|
|
Even in Windows? ;-)
|
|
bryan rasmussen - Re: Catching Uncaught Exceptions in JDK 1.5
5/31/2004; 8:27:07 AM (reads: 315, responses: 0)
|
|
|
Oh no, Windows error messages are always useful. :)
|
|
Cimarron Taylor - Re: Catching Uncaught Exceptions in JDK 1.5
5/31/2004; 11:44:30 AM (reads: 302, responses: 1)
|
|
|
That's because in absence of a good system specification, developers will tend to fall back on what the languages and libraries do and they tend to strive for generality in exception handling not realizing that the architectural requirements are usually very different.
Good exception handling requires an overall architecture to guide the developer through the coding of exceptional cases by letting them know why something should not happen, what higher level assumption is being violated when it does and lastly what the overall system should do in such a case.
Unfortunately many architects often do not understand the exceptional cases well enough before development occurs and so cannot do better.
Because of this, I generally consider how well the system handles exceptions to be a good measure of architectural quality since a well-designed system should behave as expected even when the unexpected occurs.
|
|
bryan rasmussen - Re: Catching Uncaught Exceptions in JDK 1.5
5/31/2004; 11:59:02 AM (reads: 291, responses: 0)
|
|
|
"That's because in absence of a good system specification, developers will tend to fall back on what the languages and libraries do and they tend to strive for generality in exception handling ..."
Thank you, that perfectly encapsulates the problem I'd often noted but hadn't bothered to define.
|
|
Ehud Lamm - Re: Catching Uncaught Exceptions in JDK 1.5
5/31/2004; 12:01:32 PM (reads: 301, responses: 0)
|
|
|
Too many programmers think that exceptions are a language mechanism that solves reliability problems, instead of realizing that it's a language mechanism that allows programmers to communicate exceptional occurences (mostly across routine and module boundaries). Indeed, it's just another tool for handling error, and it's not very rare that it isn't the best tool in a given situation.
|
|
|
|