CODEWITHSUNDEEP
javaexception
Ricky Tran
Ricky Tran

Reputation: 145

"why the runtime exception is un-recoverable?"

In the Java documentation, I saw the definition

"If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception"

Unchecked Exceptions — The Controversy

I don't understand clearly the concept "recover from", what does it means?

And, based on this definition, why NumberFormatException cannot recover? I think when this exception occurs, we can ask the user provide the other valid string to continue the program. Is that correct?

Upvotes: 6

Views: 2721

Answers (4)

Peter Lawrey
Peter Lawrey

Reputation: 533670

If an error occurs the developer cannot reasonably recover from it should be an Error e.g. VerifyError or NoMuchMethodError. If a condition occurs I believe should be impossible, I use AssertionError

If an error occurs which the developer might be able to recover from, though most developers are unlikely to know how to deal the exception, use a RuntimeException as this doesn't force the developer to write handling code.

If an error is being passed to the caller to deal with, even if most developers don't know how to recover from exceptions, and even if they did, might find it hard to recover from that exception, a checked exception can be used.

You can also create a Throwable or a direct sub-class which is also checked, however I only use this as a simple way to print a stack trace i.e. make it clear it's not really an error. I suggest avoiding ever throwing such as Throwable as it is confusing and very unlikely to be handled correctly.

In our code base, we might say we use Exception effectively and in many cases write both the caller and callee which is be best chance to be able to pass exceptions in a useful manner. Never the less, recovering via a fallback accounts for only 19% of our catch cases, and a "signal" accounts of 6% of cases (A "Signal" is passing a checked exception from deep in the call stack on rare occasions)

In summary we only manage to handle and recover from about 25% of exceptions/errors in the manner I believe checked exceptions are intended. I think it's a valuable 25%, but I would be happier if it was higher.

enter image description here

For the full post discussing the different ways we handle exceptions. https://vanilla-java.github.io/2016/06/21/Reviewing-Exception-Handling.html

Upvotes: 6

Manish Kothari
Manish Kothari

Reputation: 1712

"Recover From" means that the exception does not stop your program, the program can handle the exception (With the help of a try catch block) and then continue to execute.

For Example:

  • You are creating a program to search through a Employee Database.
  • If a particular employee is not found then your program is expected to recover from(handle it) it and allow the user to look for another employee.
  • In this case you may create a Checked Exception called EmployeeNotFoundException
  • A Checked Exception will prompt the programmer to handle it (Either via try catch or using throws)

Coming to why NumberFormatException is made to be a Unchecked one:

  • First of all, the rules mentioned in the question are applicable for User Defined exceptions and not the in built exceptions.
  • It is made as an Unchecked exception because they indicate a programming error.
  • It is possible to know before calling Integer.parseInt() (for example) that a Input String is a valid integer number or not. So you should perform this check before you try to parse it and not give this responsibility to the JVM.
  • You can put a try catch around a piece of code that throws an Unchecked Exception and try to handle it, but occurrence of an Unchecked Exception ideally indicates a problem that cannot be expected to handle.

Upvotes: 3

RaminS
RaminS

Reputation: 2239

The main reason behind checked exceptions seems to be to have the control over where and when you want to handle the errors. You either handle it immediately with a try-catch, or just declare that the method throws it and handle it one (or several) level higher. This also suggests that you can recover from the errors - why else would you care where you handle them?

A NumberFormatException isn't the fault of the user giving wrong input, but the programmer who didn't forsee the possibility that invalid input could be given, and is therefore not recoverable; it's essentially a bug.

Here's some more in-depth reading about exceptions: Checked vs unchecked exceptions

Upvotes: 2

Kaushik Patel
Kaushik Patel

Reputation: 239

You are correct that you can always handle Exception. try-catch block is present for the same reason. But handling all the exceptions that can result in a code can result in tedious code base. Moreover there are more scenarios in which a programmer's error in coding results in RuntimeException errors than invalid inputs provided by user.

It finally means if the functionality to be provided cannot do anything about the exception and there is not way to handle it , then the exception is to be marked as Unchecked Exception. Its upto a programmer then if he wants to handle the unchecked Exception for providing some Functionality.

Upvotes: 0

Related Questions