This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Artima Forums.
Message:
Handling OutOfMemory errors
Posted by Bharat Paliwal on 02 Jul 1998, 11:20 PM
> > is there any way of knowing that OutOfMemoryError occurred in my > > Java application? It seems like this error is automatically handled > > by AWT classes and all I can do is watch the console window for > > stack trace dumps. > Sounds like you're using 1.2! > The simple solution is to provide a top-level exception handler > of the form > try { ... } > catch (Throwable t) > { // Handle it... > } > Since Errors are subclasses of Throwable, this try/catch will > simple catch every kind of exception. > There is an alternative to this which you may find useful: > When an exception is thrown, it applies only to the current thread. > As each thread maintains its own calling stack, it is usually up to > the exception handler of one of the methods in the calling chain > to deal with any exceptions which occur. If no exception handler > is provided (e.g. we typically don't provide an exception handler > for Errors), then the stack unwinds until it reaches the initial > caller. At this point the system calls the method > uncaughtException() on the thread's thread group. The default > functionality of uncaughtException is to print a stack trace. > Now, ThreadGroup can be subclassed and the uncaughtException method > overridden. This gives the possibility to provide some last minute > functionality which can be reused in multiple contexts. > Just make sure you kick off the functionality you need in threads > or thread groups which are members of the subclassed thread > group. > Hope this is useful. > - Mike Is there a programmatic way of changing the -ms and -mx settings if the OutOfMemory error is caught? As of now all I can do is ask the user to quit and change the settings and relaunch the application. - Bharat
Replies:
|