Re: Threads and RuntimeExceptions and best practices...
Re: Threads and RuntimeExceptions and best practices...
- Subject: Re: Threads and RuntimeExceptions and best practices...
- From: Florijan Stamenkovic <email@hidden>
- Date: Tue, 01 Jul 2008 22:11:01 -0400
Hi Laurie,
May I be the first to welcome you then...
Huh, this is interesting. I've never seen this in any documentation
about the EDT, only browsing the source like you suggested revealed
this. Thanks! I will point out however that setting the default
handler through Thread's static method will cover the EDT as well,
assuming the property is not manually set.
F
On Jul 01, 2008, at 20:05, Laurie wrote:
Hello all (first post!)
For Swing apps, you probably also want to catch exceptions on the
AWT event dispatch thread. The default behaviour of this class is
to just print them to System.err and otherwise ignore them. You
change this by setting a system property:
System.setProperty("sun.awt.exception.handler",
"class.to.handle.exception");
This class must implement a method:
public void handle(final Throwable t);
If you browse source of java.awt.EventDispatchThread, a package-
private class, this is described there.
Cheers
Laurie
On 02/07/2008, at 9:47 AM, Lachlan Deck wrote:
Thanks Florijan.
On 02/07/2008, at 5:30 AM, Florijan Stamenkovic wrote:
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.
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40intrepid-geophysics.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
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