4

There is a compile time and a run time of Java code. There are checked exceptions and unchecked exceptions. Both, checked exceptions and unchecked exceptions, happen at run time.

None-the-less the base class of the unchecked exceptions is not called UncheckedException but RuntimeException. This is not directly intuitive.

How can we access the choice of name from a logical point of view? Why is it not just called UncheckedException vs. CheckedException?

Once you understand the logic behind the choice of a name, it is much more easy to work with it.

Blcknx
  • 1,921
  • 1
  • 12
  • 38
  • You are exactly right - the opposite of a runtime exception is a _checked_ exception. This is one that must be explicitly handled in the code or it will not compile. – Boris the Spider Feb 22 '18 at 21:18
  • Runtime exceptions are the ones that are supposed **not** to be caught by the program and the run should fail in case of these errors. They are meant not to be handled in the flow of the program. Compile time ones are the ones that should be referenced inside the flow to help debug the issues or throw meaningful error messages. For details about the concept of Checked and Unchecked exceptions, please refer https://stackoverflow.com/questions/6115896/java-checked-vs-unchecked-exception-explanation?rq=1 – CodeHunter Feb 22 '18 at 21:19
  • 2
    Possible duplicate of [Java: checked vs unchecked exception explanation](https://stackoverflow.com/questions/6115896/java-checked-vs-unchecked-exception-explanation) – DevelopingDeveloper Feb 22 '18 at 21:50

4 Answers4

3

Javadoc of RuntimeException says:

RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.

It's called "Runtime" because it is the superclass of exceptions that can be thrown by the "Runtime System", aka the Java Virtual Machine and the Runtime Library.

It's not about "at runtime", but about the "runtime system".

The exceptions are those that the JVM can generate, such as NullPointerException, ArrayIndexOutOfBoundsException, NegativeArraySizeException, ArrayStoreException, ArithmeticException, as well as common exceptions from the "Runtime Library" that shouldn't normally be caught (unchecked exceptions), such as IllegalArgumentException NoSuchElementException, etc.

Andreas
  • 154,647
  • 11
  • 152
  • 247
  • I would also quote the javadoc but in the facts it is not any longer. More and more runtime exceptions have to be handled. For example you can look in the JPA API the `Query.getSingleResult()` method that throws mainly Runtime exception : `NonUniqueResultException`, `NonUniqueResultException` – davidxxx Feb 22 '18 at 21:50
  • @davidxxx The question is about why the exception has the name it has, so you have to answer in the context of *when* it was named, not with all the crap that exists today. If the class was named today, it would likely be named `UncheckedException` instead, but back then, the name `RuntimeException` made sense, since it was intended for JVM generated exceptions, and common exceptions from the Runtime Library. The fact that `RuntimeException` because the de-facto `UncheckedException` base class is a different story. – Andreas Feb 22 '18 at 21:55
  • 2
    The origin of the name is even one level deeper: *"Some exceptions are thrown by the Oak **runtime** system"* - Oak Language specification, version 0.2, page 26 :-) – Marco13 Feb 22 '18 at 21:56
  • @Marco13 Dang, I got it exactly right: The "runtime system". Thanks for finding quote to prove me right. :-) – Andreas Feb 22 '18 at 22:01
  • @Andreas I am ok with your point of view. But i think that this would have deserved to be contextualized in your answer. As I read your answer, I have the impression that javadoc is still right as if developing only with a JDK was the norm and enough to build an application and that so we never need to catch RuntimeException. – davidxxx Feb 22 '18 at 22:08
  • @Marco13 oh dang! I knew it was from oak, but a page citation... Impressive! – Eugene Feb 25 '18 at 20:30
2

The compiler has no default instructions or algorithm to handle your run time exceptions. that's why its called Run Time Exceptions.

user2309604
  • 54
  • 8
  • 1
    Without knowing the real history, this answer gives in few words the most logical explanation for the choice of the name. The compiler can be fully blind towards this kind of exceptions, unless the programmer has deliberately caught them. – Blcknx Feb 22 '18 at 23:29
1

A compile time exception is NOT an exception, it is an error in the code.

Throwable is at the top off all exceptions. Underneath Throwable you have Error and Exception. Underneath Exception you have RuntimeException.

Java has two types of exceptions - checked and unchecked. Checked exceptions are enforced by the compiler (you have to declare them in the throws clause and catch them eventually). Unchecked exceptions are not enforced for catching or declaring in throws clause.

Throwable exists so that there is a parent for all exception types. You should never declare that you throw Throwable and never catch it (unless you really really really know what you are doing).

Error exists to indicate issues with the runtime environment, things that your program probably cannot recover from, such as a badly formatted class file or the VM running out of memory. You should not catch an Error unless you really know what you are doing.

Exception exists as the root for all non-programmer errors (see RuntimeException for the "exception" to this) , such as a file cannot be created because the disk is full. You should not throw, throws, or catch Exception. If you have to catch Exception make sure you know what you are doing.

RuntimeException exists to indicate all programmer error, such as going past the end of an array or calling a method on a null object. These are things that you should fix so that they do not throw exceptions - the indicate that you, the programmer, screwed up the code. Again, you should not catch these unless you know what you are doing.

Read : https://docs.oracle.com/javase/tutorial/essential/exceptions/

Nard Dog
  • 906
  • 1
  • 18
  • 33
1

Is it just an unfortunate choice of name?

It is just a way to differentiate them.

Checked and no checked exceptions derive from the same base class : Exception.
Exception is checked at compile time and RuntimeException is not.
The Runtime prefix conveys that the RuntimeExceptions are designed to be thrown at runtime without that client code needs to handle them at compile time.

As said in my comment : Exception and UnCheckedException would be more natural as we often refer to checked and unchecked exceptions as we talk about them. Now, things are done since a long time and the API cannot be modified and replaced.

davidxxx
  • 125,838
  • 23
  • 214
  • 215
  • So we can say both happen at runtime, but only one is supposed to be seen at runtime? – Blcknx Feb 22 '18 at 21:35
  • For the first part yes. For the second, no. Both are seen at runtime. The difference is that the compiler enforces that checked exceptions be handled at compile time while runtime exceptions don't have this constraint and can so stop a flow execution if the client code doesn't add catch statements to handle them while these are not mandatory to compile. – davidxxx Feb 22 '18 at 21:43
  • The compiler enforces to catch the "non-runtime" exceptions somehow, so they are not to be seen at runtime by the user. Right? Still I think checked vs. unchecked would be a less misleading naming. Especially as the so called runtime exceptions are not always be seen by the user at runtime but may also be caught and logged. – Blcknx Feb 22 '18 at 21:50
  • "so they are not to be seen at runtime by the user. " These should indeed. Note that in practice, nothing prevents to handle incorrectly the checked exception and to let it to be propagate to the client by declaring `throws Exception`. You mind is not wrong. `CheckedException`/`Exception` and `UnCheckedException` would be more natural as we often refer to checked and unchecked exceptions as we talk about them. Now, things are done since a long time and the API cannot be modified and replaced. – davidxxx Feb 22 '18 at 21:56