RuntimeException & Error

Question

In the exceptions hierarchy, the descendants of RuntimeException and those of Error are runtime exceptions/errors.

The difference between the two is: Those under RuntimeException are the ones caused by poor programming/design, and those of Error are the ones that can't/shouldn't be controlled by the developer.

For coding an exception within the application, for instance, to throw an exception when something in the business logic occurs, the RuntimeException is extended.

The question is, what exactly is the difference between extending RuntimeException and extending Error-- except that extending Error is bad practice?

Who says that it *is* bad practice? Certainly not something you'd do every day, but I don't doubt that there are cases where it might be merited. — Hot Licks, Dec 09 '13 at 02:00
@HotLicks Joshua Bloch recommends to do so in his book Effective Java: "While the Java Language Specification does not require it, there is a strong convention that errors are reserved for use by the JVM to indicate resource deficiencies, invariant failures, or other conditions that make it impossible to continue execution. Given the almost universal acceptance of this convention, it’s best not to implement any new Error subclasses. Therefore, **all of the unchecked throwables you implement should subclass** `RuntimeException` (directly or indirectly)." — Nir Alfasi, Jan 09 '14 at 20:06
@alfasin - So the XYZ operating system might detect a hardware failure while retrieving the system clock, but it shouldn't call that an Error? An API that controls the valves in a chemical plant might detect a hardware failure and again should not call it an Error? — Hot Licks, Jan 09 '14 at 20:24
@HotLicks In the same chapter, Joshua says that `RuntimeException` should indicate "programming errors", for example, invalid pre-conditions when calling a method. The specific case you describe (HW failure) may potentially crash the JVM (in which case, an `Error` will be raised) but anyways, it does not sound like "programming error". I guess that the answer depends on how such a problem will effect your program/OS. It's important to remember that there's no behavioral difference between `RuntimeException` and `Error` - only semantic which is why `RuntimeException` would probably still fit. — Nir Alfasi, Jan 09 '14 at 23:54
@alfasin - So you're saying that his reason is all about semantics, with no real purpose. — Hot Licks, Jan 10 '14 at 01:07
@Hot Licks this convention, like any convention, is arbitrary. — Nir Alfasi, Jan 10 '14 at 05:44

score 27 · Answer 1 · edited Jun 03 '17 at 13:57

27

Both Error and RuntimeException are unchecked exceptions, meaning that it indicate a flaw with the program, and usually should not be caught. (NullPointerException, IndexOutOfBoundsException, etc.)

I think the main difference between the two is that RuntimeException indicate there is a error with the program, and an Error is something that is fatal but out of the program's control. (OutOfMemorryError, ThreadDeath, etc.)

Therefore subclassing an Error is bad practice because an error is usually not something that could be fixed by your program at runtime. In your program, should you need to throw something, use an Exception.

edited Jun 03 '17 at 13:57

Genhis

1,484
3
27
29

answered Dec 09 '13 at 01:51

Pita

1,444
1
19
29

i bolded the part that i think should answer your question – Pita Dec 09 '13 at 02:11
1

Something else that cannot be fixed by your program at runtime are bugs in the code. Therefore assertion exceptions can legitimately subclass `Error` (or better yet, `AssertionError` which is an `Error` subclass). – Marcus Junius Brutus Mar 08 '17 at 14:54

score 9 · Answer 2 · answered Dec 09 '13 at 01:58

The Q is, what exactly is the difference between extending RuntimeException and extending Error-- except that extending Error is bad practice?

You've already mentioned the main differences. The Java Language Specification says the same thing in different terms. For Error, it states

Error is the superclass of all the exceptions from which ordinary programs are not ordinarily expected to recover.

For RuntimeException, it states

The class RuntimeException is a direct subclass of Exception. RuntimeException is the superclass of all the exceptions which may be thrown for many reasons during expression evaluation, but from which recovery may still be possible.

What you should take away from these quotes is that you will commonly see

try {
   ...
} catch (Exception e) { // catches RuntimeException
   ...
}

as a catch all case since Exception is a super type of RuntimeException. But you will almost never see (I've never seen it)

try {
   ...
} catch (Error e) {
   ...
}

RuntimeException & Error

2 Answers2