Catching java.lang.OutOfMemoryError?

Question

Documentation for java.lang.Error says:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application

Answer 1

OOME can be catched but is going to be generally useless, depending on if the JVM is able to garbage collect some objects when the catch is reached, and how many heap memory is left by that time.

Example: in my JVM, this program runs to completion:

import java.util.LinkedList;
import java.util.List;

public class OOMErrorTest {             
    public static void main(String[] args) {
        List<Long> ll = new LinkedList<Long>();

        try {
            long l = 0;
            while(true){
                ll.add(new Long(l++));
            }
        } catch(OutOfMemoryError oome){         
            System.out.println("Error catched!!");
        }
        System.out.println("Test finished");
    }  
}

However, just adding a single line on the catch will show you what I'm talking about:

import java.util.LinkedList;
import java.util.List;

public class OOMErrorTest {             
    public static void main(String[] args) {
        List<Long> ll = new LinkedList<Long>();

        try {
            long l = 0;
            while(true){
                ll.add(new Long(l++));
            }
        } catch(OutOfMemoryError oome){         
            System.out.println("Error catched!!");
            System.out.println("size:" +ll.size());
        }
        System.out.println("Test finished");
    }
}

The first program runs fine because when the catch is reached, the JVM detects that the list isn't going to be used anymore (This detection can be also an optimization made at compile time). So when we reach the print statement, the heap memory has been freed almost entirely, so we now have a wide margin of maneuver to continue. This is the best case.

However, if the code is arranged such as the list ll is used after the OOME has been catched, the JVM is unable to collect it. This happens in the second snippet. The OOME, triggered by a new Long creation, is catched, but soon we're creating a new Object (a String in the System.out,println line), and the heap is almost full, so a new OOME is thrown. This is the worst case scenario: we tried to create a new object, we failed, we catched the OOME, yes, but now the first instruction requiring new heap memory (e.g: creating a new object) will throw a new OOME. Think about it, what else can we do at this point with so little memory left?. Probably just exiting. Hence the useless.

Among the reasons of the JVM not collecting resources, one is really scary: a shared resource with other threads also making use of it. Anyone with a brain can see how dangerous catching OOME can be if inserted on some non-experimental app of any kind.

I'm using a Windows x86 32bits JVM (JRE6). Default memory for each Java app is 64MB.

Answer 2

I came across this question because I was wondering whether it is a good idea to catch OutOfMemoryError in my case. I'm answering here partially to show yet another example when catching this error can make sense to someone (i.e. me) and partially to find out whether it is a good idea in my case indeed (with me being an uber junior developer I can never be too sure about any single line of code I write).

Anyway, I'm working on an Android application which can be run on different devices with different memory sizes. The dangerous part is decoding a bitmap from a file and dislaying it in an ImageView instance. I don't want to restrict the more powerful devices in terms of the size of decoded bitmap, nor can be sure that the app won't be run on some ancient device I've never come across with very low memory. Hence I do this:

BitmapFactory.Options bitmapOptions = new BitmapFactory.Options(); 
bitmapOptions.inSampleSize = 1;
boolean imageSet = false;
while (!imageSet) {
  try {
    image = BitmapFactory.decodeFile(filePath, bitmapOptions);
    imageView.setImageBitmap(image); 
    imageSet = true;
  }
  catch (OutOfMemoryError e) {
    bitmapOptions.inSampleSize *= 2;
  }
}

This way I manage to provide for more and less powerful devices according to their, or rather their users' needs and expectations.