On Friday 14 January 2005 13:24, Andrew Haley wrote: > Chris Burdess writes: > > Andrew Haley wrote: > > > Indeed. The problem is that anything you do when catching an > > > OutOfMemoryException risks running out of memory! There's not much > > > any java program can do other than logging the failure and exiting. > > > > To be pedantic, it's OutOfMemoryError, > > Ahh, cut 'n paste. > > > and the same applies largely to any other Error (except possibly in > > the case of reflection tools). > > Not really. For example, it's not unreasonable to catch > java.lang.NoClassDefFoundError, which may be thrown when a subsystem > is badly configured.
J2ME CLDC VMs are not required to handle Errors via the exception handling mechanism, which kind of implies that other VMs should try to do so. An application _could_ handle an OOME by switching to a less memory-intensive algorithm or flushing caches, but I doubt that many do. It's a bit like doing something other than exit() when malloc returns NULL; a good idea in a compiler, but probably more trouble than it's worth in a run-off-the-mill app. My own experience is that the feasibility of cleanly throwing OOME depends strongly on the complexity of the application. If you have 101 threads all trying to load classes and stuff then you'll probably end up with an OOME storm and end up crashing in the VM: with a single-threaded application you'll probably be able to throw the OOME, catch it in the uncaughtExceptionHandler of the root ThreadGroup, and do a clean exit. -- Chris Gray /k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 3 216 0369 Visit us at Embedded World 2005 <http://www.embedded-world.de/> 22--24 Feb. 2005 at the Nürnberg Messe (Germany), booth 10-504 _______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath