home / java / why-we-shouldnt-catch-errors-in-java-even-though-we-can
Java

Why We Shouldn’t Catch Errors in Java (Even Though We Can)

This is one of the most common Java interview questions. The statement:

“Errors represent serious problems that applications generally should not catch, whereas exceptions are conditions that applications can handle.”

does not mean that Error cannot be caught. It can be caught because Error also extends Throwable.

Object
|
Throwable
|----------------------|
Exception Error

The point is whether you should catch it.


Example 1: Catching an Error

Let’s create a StackOverflowError.

public class Main {

public static void recursiveMethod() {
recursiveMethod();
}

public static void main(String[] args) {

try {
recursiveMethod();
} catch (StackOverflowError e) {
System.out.println("Caught Error : " + e);
}

System.out.println("Application continues...");
}
}

Output

Caught Error : java.lang.StackOverflowError
Application continues...

So yes…

✅ Java allows this.


Example 2: OutOfMemoryError

public class Main {

public static void main(String[] args) {

try {

int[][] arr = new int[1000000][];

for (int i = 0; i < arr.length; i++) {
arr[i] = new int[1000000];
}

} catch (OutOfMemoryError e) {

System.out.println("Memory exhausted!");

}

System.out.println("Program finished");
}
}

Again,

Memory exhausted!
Program finished

It catches the error.


But Why Does Java Say We Shouldn’t Catch Errors?

Because catching the error doesn’t solve the underlying problem.

Suppose your server runs out of memory.

Request

Application

Need Memory

No Memory Left

OutOfMemoryError

Now imagine you catch it.

catch (OutOfMemoryError e) {
System.out.println("No problem!");
}

Has memory become available?

❌ No.

The JVM is still out of memory.

The application is now running in an unstable state.


Another example

Suppose a building catches fire.

You do this:

Fire!!



Catch



Ignore



Continue working

Did the fire disappear?

No.

The building is still burning.

Errors are similar.


Real Production Example

Suppose your application has

4 GB Heap

Suddenly

Millions of records loaded



Heap Full



OutOfMemoryError

Even if you do

catch (OutOfMemoryError e) {
logger.error("OOM occurred");
}

Can the application safely process the next request?

Usually No.

Objects may not be created anymore.

Threads may fail.

GC may keep running.

The JVM may become unstable.

Therefore the safest action is usually to let the JVM terminate or restart.


Then Why Can We Catch Errors?

Sometimes we only want to

  • log the problem
  • clean up resources
  • generate a crash report
  • notify monitoring systems

Example:

try {
startApplication();
}
catch (OutOfMemoryError e) {

logger.error("Fatal JVM Error", e);

// Notify monitoring system
// Flush logs
// Release native resources

throw e; // Don't hide it
}

Notice the important part:

throw e;

We log it…

then rethrow it.

We are not pretending the application is healthy.


What is the Proper Way?

❌ Wrong

try {
processOrder();
}
catch (Error e) {
// Ignore

System.out.println("Everything is fine.");
}

This hides a fatal JVM problem.


❌ Also Wrong

try {

}
catch(Throwable t) {

}

Because this catches

  • Exception
  • RuntimeException
  • Error

You may accidentally swallow fatal JVM errors.


✅ Better

Catch only expected exceptions.

try {
readFile();
}
catch (IOException e) {
logger.error("Unable to read file", e);
}

✅ If you absolutely catch an Error

Log it and rethrow it.

try {

startApplication();

}
catch (OutOfMemoryError e) {

logger.error("Fatal Error", e);

throw e;
}

When is Catching an Error Acceptable?

Very rarely.

Typical cases include:

1. Crash Reporting

try {
runApplication();
}
catch (Error e) {
crashReporter.send(e);
throw e;
}

2. Logging Before Shutdown

catch (StackOverflowError e) {

logger.error("Stack overflow occurred");

throw e;
}

3. JVM Frameworks

Frameworks such as application servers, IDEs, profilers, or monitoring agents may catch Error briefly to:

  • collect diagnostics,
  • write logs,
  • perform minimal cleanup,

and then rethrow the Error.

Normal business applications generally should not do this.


Interview Answer

Can we catch an Error in Java?

Answer:

Yes. Since Error extends Throwable, Java allows us to catch it. However, we generally should not catch it because it represents serious JVM-level problems such as OutOfMemoryError, StackOverflowError, or VirtualMachineError. These errors usually indicate that the application is in an unstable state and cannot recover safely. If an Error is caught, it should typically be used only for logging or cleanup before rethrowing it, rather than attempting to continue normal execution.


Quick Summary

ExceptionError
RecoverableUsually not recoverable
Business/application problemJVM/system-level problem
Applications should catchApplications generally should not catch
Example: IOExceptionExample: OutOfMemoryError
Continue execution after handlingUsually terminate or restart after logging
Commonly handledRarely caught, and if caught, typically rethrown after logging

Rule of thumb: Catch exceptions you can meaningfully recover from. If you catch an Error, do it only for diagnostics or essential cleanup, then rethrow it rather than continuing as if nothing happened.