6

While programming in java is there any time that I as the programmer should be considering to catch RuntimeExceptions ?

ManuPK
  • 11,623
  • 10
  • 57
  • 76
Geek
  • 26,489
  • 43
  • 149
  • 227

5 Answers5

8

You catch RuntimeException for the same reason that you catch any exception: you plan to do something with it. Perhaps you can correct whatever caused the exception. Perhaps you simply want to rethrow with a different exception type.

Catching and ignoring any exception, however, is extremely bad practice.

  • 1
    Im not sure that you should really be doing that with unchecked exceptions. They really only should be thrown where there is nothing else that can be done and basically just represent bugs in your code. That being the case the only real reason to catch one is to protect your application from blowing up (if it is possible top do so). – John Kane Jul 16 '12 at 15:27
  • Agreed, if there is no other way of validating code, throw an exception! –  Jul 16 '12 at 15:34
  • I am not sure what you mean by validating code? What I meant was that the only time runtime exceptions should be thrown are when there is nothing that can be done. For example, BufferOverflow, BufferUnderflow, ClassCast, ConcurrentModifications, etc are all runtime exceptions. These do not have anything really to do with validating code. You cannot really do anything about them if they happen, except basically try to recover if possible or let your application die. It depends on what your application is doing. – John Kane Jul 16 '12 at 16:06
2

This is what I can think of.

  1. If you want to show a nice message to the end user in case something has gone wrong, catch the RuntimeException and log it. Then show some nice message in the screen instead of a blasting error.
  2. To wrap the framework specific CheckedExceptions to application specific RuntimeExceptions.It is preferred to use the RuntimeException as your custom exception as told here.
ManuPK
  • 11,623
  • 10
  • 57
  • 76
0

Based on user validation if want to show custom message to the user then go for RuntimeException.

Wrap your custom message in then throw it.

throw new RuntimeException("Invalid userName/Password !");
amicngh
  • 7,831
  • 3
  • 35
  • 54
0

Basically, the only time you would want to catch one is when you cannot allow your application to blow up. This is a good article describing this in much more detail, but here is a quote that sums it up:

"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".  

Since unchecked exceptions are basically just bugs in your code and by really should only be thrown where there is nothing that can be done about them, the only real time that you would want to catch one is when you cannot allow your application to blow up.

John Kane
  • 4,383
  • 1
  • 24
  • 42
-1

Yes: whenever you can and want to recover from them.

Many common exceptions inherit from RuntimeException and each may or may not be recoverable depending on the particular circumstances. The RuntimeException class itself does not imply that the exception must or must not be caught.

For example, you may have a library method which throws IllegalArgumentException on certain inputs. If applicable to your program, you could catch this exception and recover in some way, for example by trying a different input, or explaining to the user why the operation cannot continue.

Rich
  • 15,048
  • 2
  • 66
  • 119