«

Hi,
I am working on a project in which when i run out of memory, I get a
"Java.lang.outofmemory" exception. But I am not able to catch this !
i.e is every function has a try catch statement. But I am not able to
get hold of this exception.

Well u might be wondering what i wud like to do after catching it....
well I'd like to tell the user that his memory is over !!

Am I not able to catch it? or doesnt java has a way to catch this
exception?

plz help,
regards,
Rajesh Rapaka.

On Wed, 13 Jul 2005 10:08:37 +0100, Rajesh.Rapaka
<> wrote:

> Hi,
> I am working on a project in which when i run out of memory, I get a
> "Java.lang.outofmemory" exception. But I am not able to catch this !
> i.e is every function has a try catch statement. But I am not able to
> get hold of this exception.
>
> Well u might be wondering what i wud like to do after catching it....
> well I'd like to tell the user that his memory is over !!
>
> Am I not able to catch it? or doesnt java has a way to catch this
> exception?

You don't have to catch it for every method call, just for every thread on
which it could occur since it will propagate up the call stack. If you
are using Java 5 this is made easy by the new
Thread.setUncaughtExceptionHandler method. If not, you would need to put
a try...catch around the code in your main method and the code in the run
methods of any threads you spawn.

But you will have to be careful what you do when you catch it since you
won't have much/any memory to work with, so it might not work reliably.

Dan.

--
Daniel Dyer
http://www.dandyer.co.uk

On 13 Jul 2005 02:08:37 -0700, Rajesh.Rapaka wrote:

> I am working on a project in which when i run out of memory, I get a
> "Java.lang.outofmemory"

No such error!

>..exception. ...

No you don't. What you are getting is an *error*,
not an exception. Assuming you mean..
<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/OutOfMemoryError.html>

Please copy/paste errors, rather than typing 'something like'
what it says. That wastes your time and our bandwidth.

See below..

>..But I am not able to catch this !
> i.e is every function has a try catch statement. But I am not able to
> get hold of this exception.
>
> Well u might be wondering what i wud like to do after catching it....
> well I'd like to tell the user that his memory is over !!
>
> Am I not able to catch it?

Sure you are..

Are you catching Exceptions[1], ..or Errors[2]?

(note that while both are Throwable[3],
// do dangerous stuff
...
} catch(Exception e) {

....will not catch classes under the Error hierarchy.)

[1] <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Exception.html>
[2] <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Error.html>
[3] <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html>

--
Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
== Proudly Made On Earth ==

"Daniel Dyer" <> schrieb im Newsbeitrag news...
> On Wed, 13 Jul 2005 10:08:37 +0100, Rajesh.Rapaka
> <> wrote:
>
> > Well u might be wondering what i wud like to do after catching it....
> > well I'd like to tell the user that his memory is over !!
> >
> > Am I not able to catch it? or doesnt java has a way to catch this
> > exception?
>
> You don't have to catch it for every method call, just for every thread on
> which it could occur since it will propagate up the call stack.

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

I'm of the opinion that something like an "OutOfMemoryError" and just about
any other thing that ends with "Error" should not be caught. Its not
really a bug or problem in your code its a problem with the environment the
program is running in. Let the user see the problem. Your code needs to do
something and the user has a PC with either not enough memory or just too
much stuff currently running. Your code can't fix it. The user needs the
smack upside the head to get a better system or shut some junk down.

On Mon, 18 Jul 2005 02:34:58 GMT, E.Otter wrote:

> I'm of the opinion that something like an "OutOfMemoryError" and just about
> any other thing that ends with "Error" should not be caught.

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.

>..Its not
> really a bug or problem in your code its a problem with the environment the
> program is running in.

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.

> Let the user see the problem.

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

--
Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
You Can't Prove It Won't Happen

E.Otter wrote:
> I'm of the opinion that something like an "OutOfMemoryError" and just about
> any other thing that ends with "Error" should not be caught. Its not
> really a bug or problem in your code its a problem with the environment the
> program is running in. Let the user see the problem. Your code needs to do
> something and the user has a PC with either not enough memory or just too
> much stuff currently running. Your code can't fix it. The user needs the
> smack upside the head to get a better system or shut some junk down.

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.

On 18 Jul 2005 00:42:03 -0700, wrote:

> 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.

60% of the time?! When I was fighting memory leaks in some
image software - I found I could get a dialog every time so
long as I'd prepared and packed it first (ready - just in case).

OTOH, I also like the idea mentioned by Martin (# 3).
<http://groups-beta.google.com/group/comp.lang.java.programmer/msg/01e160bb68b85329>
Instant emergency memory!

--
Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
A By-Product Of The TV Industry

Andrew Thompson wrote:
> On 18 Jul 2005 00:42:03 -0700, wrote:
>
> > 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.
>
> 60% of the time?! When I was fighting memory leaks in some
> image software - I found I could get a dialog every time so
> long as I'd prepared and packed it first (ready - just in case).
>
> OTOH, I also like the idea mentioned by Martin (# 3).
> <http://groups-beta.google.com/group/comp.lang.java.programmer/msg/01e160bb68b85329>
> Instant emergency memory!
>
> --
> Andrew Thompson
> physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
> A By-Product Of The TV Industry

Hi, Andrew,

Thanks for the link; I've toyed with this technique (admittedly to no
great extent) and couldn't quite get it to work. This thought was
floating in my head that probably sabotaged my attempts: surely just
setting the variable to null won't force the garbage collector to
immedately free the memory before the next line is executed? Surely
setting the variable to null just identifies it for collection
*whenever* the garbage collector decides to get off his sofa and do
some work?

I will, however, put more effort into pre-manufacturing a JDialog,
though; I had no idea that this sort of problem could be handled with
100% satisfaction.

Ta, chuck,

..ed

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

On 19 Jul 2005 00:58:34 -0700, wrote:

> Andrew Thompson wrote:
...
>> 60% of the time?! When I was fighting memory leaks in some
>> image software - I found I could get a dialog every time so
>> long as I'd prepared and packed it first (ready - just in case).
...
> I will, however, put more effort into pre-manufacturing a JDialog,
> though; I had no idea that this sort of problem could be handled with
> 100% satisfaction.

100% satisfation guaranteed - or your money back!

But, more seriously.. If you ever see that fail, I
would be interested in hearing about it.

--
Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
Where No Fan Has Gone Before