avoid lot of try/catch blocks

[evgueni.titov]

Hello,

Is it possible in Java to write a "global" try/catch block which will
monitor exceptions in all threads?
In my application I have 20 JFrames and 10 methods in it, I just can't
write 200 try/catches
I've researched for several hours but haven't found any answer.

Thank you.

 

[Thomas Kellerer]

(e-mail address removed), 08.02.2008 12:17:

Hello,

Is it possible in Java to write a "global" try/catch block which will
monitor exceptions in all threads?
In my application I have 20 JFrames and 10 methods in it, I just can't
write 200 try/catches
I've researched for several hours but haven't found any answer.

Thank you.

Maybe setDefaultUncaughtExceptionHandler() is what you are looking for:

<http://java.sun.com/j2se/1.5.0/docs...er(java.lang.Thread.UncaughtExceptionHandler)>

Thomas

 

[evgueni.titov]

Thanks!! But it works since 1.5, and unfortunately, I am using 1.4...
Any ideas?

 

[evgueni.titov]

I've found the answer: you have to create a class that will handle the
exception:
public class Handler {

/** Creates a new instance of Handler */
public Handler() {
}

public void handle (Throwable t){
System.out.println(null, "Error: "+ t.getMessage() + "\nCause:
" + t.getCause().getMessage());
System.exit(1);
}
}

and then register it: System.setProperty("sun.awt.exception.handler",
"Handler");
(it works for awt/swing)

 

[Mike Schilling]

Hello,

Is it possible in Java to write a "global" try/catch block which will
monitor exceptions in all threads?
In my application I have 20 JFrames and 10 methods in it, I just can't
write 200 try/catches

There's no need to do that. Write a class like this (not tested or even
compiled, but I think the idea is clear).

class Catcher implements Runnable
{
private Runnable toRun;

public Catcher(Runnable toRun)
{
this.toRun = toRun;
}

public run()
{
try
{
toRun.run();
}
catch (Exception ex)
{
// Handle all exceptions here
}
}
}

Anywhere you start up a thread, create a new Catcher to be the object that
gets run; now every uncaught exception from every one of those threads
will be caught by that single catch block.

 

[Roedy Green]

Thanks!! But it works since 1.5, and unfortunately, I am using 1.4...
Any ideas?

I learned the other day that Mac people are stuck on 1.5. What group
are stuck on 1.4? That's a bit long in the tooth, 42+ years old in
Internet years.

J2SE 1.4.0 2002-02-13 Merlin

J2SE 1.5.0 2004-09-29 Tiger

see http://mindprod.com/jgloss/internetyear.html

 

[Lew]

I learned the other day that Mac people are stuck on 1.5. What group
are stuck on 1.4? That's a bit long in the tooth, 42+ years old in
Internet years.

J2SE 1.4.0 2002-02-13 Merlin

J2SE 1.5.0 2004-09-29 Tiger

see http://mindprod.com/jgloss/internetyear.html

I don't know about the OP, but where I work a substantial portion of the
Enterprise Java applications are running on Java 1.3, and that's been
officially retired for a while. The rest are running on 1.4. As far as I
know, none of the production apps are running on Java 5 or later.

Java shops on 1.4 are common - only now are a few of these organizations
reluctantly and cautiously moving to Java 5, a product itself due to enter
End-of-Life this year. This is a widespread phenomenon, the reluctance to
move forward through Java versions.

I thought it strange for a while - 42+ years in software years seems awfully
old, until I realized that this isn't limited to Java. Oh, sure, their
Windows desktops are all pretty much XP (SP2) now, but the production
databases in many organizations are just coming off Oracle 8.

The problem is when you're dealing with millions, billions, or even trillions
of dollars, Euros or whatever (many government agencies around the world use
Java Enterprise systems), one becomes reluctant to "upgrade" a functioning
system. Risk management becomes the critical decision factor, and only when
the risks of an old platform sufficiently overbalance the risks of change are
these organizations willing to move.

So the short answer to "what group are stuck on 1.4" is "most production
systems, if they've progressed that far yet".

Me, I usually push places where I do Java to at least progress to Java 5.
this is selfish - as a programmer I find that the minimum platform to be
sufficiently productive. Not only is Java 5+ easier to program and more
reliable (thanks to the improvements in the memory model, for example), but
the concomitant technologies like Java Server Faces and JSP Expression
Language really need Java 5 to work properly. To pay back the organization
for indulging that selfishness, I aim to mitigate the upgrade risks for them.
Thus they win, getting an easier upgrade in the areas where they permit me
to do this, and getting a more reliable and productive platform into
production as a result.