Are Runtime Exceptions thrown even when they have been caught?

Question

I have a method which writes in database but if it is not able to write in database then I catch it as Runtime exception using Exception Class.

public fun()
{
  try
  {
        writeInDb(....);
  }
  catch(Exception E)
  {
       //log the event
  }
}

Now I have another function calling this function fun() but it also catches exception and based on outcome it sends message to client whether successful or not. e.g.:

funA()
{
   try
   {
      fun();
   }
   catch(Exception E)
   {
       //send message to user
   }
}

I have a doubt here that since in fun() I have caught the runtime exception so will funA be able to know that an exception has occurred, so that it may send right message.

`funA()` will only see the exception if you let `fun()` rethrow it after catching it. This is something you could have easily tried with a few lines code... — jlordo, May 19 '13 at 11:40
It's not `Exception Class`, it's `Exception variable`. `Exception` here is the class that subclasses `Throwable` that you want to catch. If you only want to catch RuntimeExceptions, use `catch (RuntimeException e)` — Simon Forsberg, May 19 '13 at 11:42
@SimonAndréForsberg I think SIGSTP's *Runtime Exceptions* means runtime-error, opposite of compile-error. — johnchen902, May 19 '13 at 11:43
I understood it as the only Exception that is wanted to catch here is: http://docs.oracle.com/javase/6/docs/api/java/lang/RuntimeException.html . But ok, I might be wrong there. But `E` is still a variable and not a class and should according to the coding standards be written lowercase. — Simon Forsberg, May 19 '13 at 11:46
@SimonAndréForsberg - Technically, that's "coding conventions", unless you work inside an organization that has declared them as "standards". — Hot Licks, May 19 '13 at 12:12

altsyset · Answer 1 · 2013-05-19T11:50:17.293

2

if you caught the exception in fun(), funA() wont be able to recognize it. It would be able to catch it if fun() throws it

edited May 19 '13 at 11:50

answered May 19 '13 at 11:43

altsyset

339
2
20

score 2 · Answer 2 · answered May 19 '13 at 11:53

2

No exceptions (runtime or checked) are re-thrown if you catch it and handle it.

Once an exception is caught in a method then you have to decide whether this method should handle the exception or re-throw it so that the caller can handle it.

answered May 19 '13 at 11:53

Narendra Pathai

41,187
18
82
120

score 2 · Answer 3 · edited May 23 '17 at 12:05

altsyset is perfectly right.

I just wanted to add that Exceptions should not be used as a means of data transport. If you deal with the exception in fun(), react accordingly! Use fun()'s return value to inform funA() of the error - or throw a new, meaningful exception if you absolutely must have one.

This isn't only a question of style but of performance - exception handling slows down your program, so you shouldn't throw them around lightly (pun intended). This question provides some discussion of that, but the consensus seems to be that excessive use of exceptions is undesirable.

Stephen C · Answer 4 · 2013-05-20T00:32:28.467

The answer is that funA will not see the exception that is thrown by writeDB because fun has caught it.

You could rethrow it in fun, like this:

  catch (Exception e) {
       //log the event
       throw e;
  }

However, there's a problem. If you do that, the compiler will now complain that fun needs to be declared as throwing Exception. (And this "infection" is likely to spread ...)

The correct solution is NOT to catch Exception. Instead you should catch RuntimeException; e.g.

  catch (RuntimeException e) {
       //log the event
       throw e;  // Now the compiler knows that the exception is unchecked
                 // and therefore we don't need to declare it in the method
                 // signature.
  }

Or better still, catch the explicit subclasses of RuntimeException that you are expecting at that point ... or even better still (IMO), change writeInDb to throw specific CHECKED exceptions.

The problem with catching Throwable/Exception/RuntimeException is that you often end up catching all sorts of unexpected exceptions that your code can't effectively handle. It is better to catch the ones you are expecting and let the rest pass through. If you catch everything there's a good chance that you will end up burying the ones that are actually caused by bugs ... making it harder to debug them.

Are Runtime Exceptions thrown even when they have been caught?

4 Answers4