Threads and RuntimeExceptions and best practices...
Threads and RuntimeExceptions and best practices...
- Subject: Threads and RuntimeExceptions and best practices...
- From: Florijan Stamenkovic <email@hidden>
- Date: Tue, 01 Jul 2008 15:30:06 -0400
Hi all,
This is not a question, but an extension of the subject that Chuck
addressed in the Best Practices at WOWODC. His point was, never just
swallow an exception. I agree, should be done virtually never. My
practice, when there is not a specialized fix for the shituation, is
to do it like this:
try{
...
}catch(SomeException ex){
ErrorHandler.handleException(ex);
}
The ErrorHandler is an app dependent implementation, in a Swing app
for example I would give a nice dialog telling to the user that the
app, alas, crashed, save the log, send it to myself, blah blah. You
get the drift.
BUT!
This does not take care of RuntimeExceptions. I wanted to take care
of that. My first impulse was to define my own thread subclass, try
to catch whatever kind of an exception, and deal with it from there.
But then I decided to first check out the Thread API in detail, to
see if I see it clearly enough, and I stumbled upon two nice things
in the Thread class:
public static void setDefaultUncaughtExceptionHandler
(Thread.UncaughtExceptionHandler eh)
public void setUncaughtExceptionHandler
(Thread.UncaughtExceptionHandler eh)
Now I forward also RuntimeExceptions (though one should be careful in
generically handle them, you never know when they occur) to my
ErrorHandler, with a few lines of code, and I am happy.
Thought I'd share this, perhaps there are others who were not
familiar with those two methods, like I was not.
My best,
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden