I'm fighting myself  with this problem right now.
So here are my findings/observations: (In no particular order)
1.
You also need to be aware of your AWT/Swing threads.
You need to catch the error in each of them (besides the threads you started explicitly)
One point would be the ActionListener kicking off your action.

2.
(And probably most important) OutOfMemory is an "Error" not an Exception.
So if you catch Exceptions, you simply will miss the Errors.
So you have to catch the specific Error, all Errors or maybe even Throwable.
(But then you get all of them...)

3.
If you have no memory left, it seems the handling may well trigger at once the next OutOfMemory.
So you need a trick like that: (Borrowed from an older posting I found with google)

private static byte[] emergencyMem = new byte[8192];
public .... main(String[] a) {
  try {
    runApplication();
  } catch (OutOfMemoryError e) {
    emergencyMem = null;
// ...Rest of handling
  }
}

HTH

Martin

As a general rule - that is idiotic.

Window.setAlwaysOnTop() is a method introduced in 1.5.
If you try it in a pre 1.5 VM you will get a 'NoSuchMethodError',
but that is no reason to throw an error up before the end user.
The programmer can simply start a thresad that keeps bringing the
desired window to front.  Not as neat and elegant as 'AlwaysOnTop',
but still entirely workable.

OOME's can be handled in a better manner by the programmer
as well.

Like program designed to load up to 50 images is asked to
load 327?  Yes, it might be a problem with the environment,
or how the user is using/abusing the program ..but simply
dumping an error to stderr and exiting is most often neither
necessary nor optimal.

Tell 'em nothing, if you don't have to.  It only confuses them.

FWIW, I'm not of that opinion.

I recently wrote a GUI for an application: this application reads and
analyses loads of files. If the user tries to analyse too large a
system, then the application will run out of memory.

The problem is that when this OutOfMemoryError is thrown by the
application, if it's not caught, then the GUI will just hang. It won't
report the Error automatically. Thus the user waits for a while,
guesses something's gone horribly wrong, and rips it all down.

It's much better to throw up a warning dialog, telling him that the
universe is  finished and he might as well give up.

Yes, I know: you cannot guarantee that there will be enough memory to
throw up the dialog, but I tried, nonetheless, and testing has shown
that the system will throw up the dialog 60% of the time. Yes, for the
other 40%, the user is just waiting for the bus that will never come;
but 60% is better than nothing.

Also, I've noticed that, even when there's no memory to throw up a
dialog, the JVM can always (apparently) do a System.out.println(); so I
do this, too. Unfortunately, most users will start the application by
double-clicking a jar file, in which case the println() sends the
message into deep space somewhere; but again: a little effort can *try*
to allieviate the user's frustration.

.ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.