In Java, is there a way to recatch or list an exception that was previously caught

Question

I have an API that I cannot modify which does basically the following:

public void CatchException() {
  try {
    some code...
  } catch (Throwable t) {
    System.out.println(t.toString());
  }
}

I am calling this API in my method:

public void myMethod() {
  try {
    someClass.CatchException();
  } catch (Throwable t) {
     ... exception is not recaught
  }
}

In the call to the API, the exception is not caught a second time as it was consumed in the API method... This is expected Java behaviour...

Is there a way for me to detect that the exception was thrown in the API method without being able to modify the code of the API?

So you want to be able to detect the exception in both `myMethod` and `CatchException`? — Austin, Sep 11 '15 at 21:11
Can you extend this class and override CatchException method? — Iłya Bursov, Sep 11 '15 at 21:13
Well you could always parse the contents of the console (System.console()) for the exception string. — Soggiorno, Sep 11 '15 at 21:13
No, you can't do this without modifying `CatchException` or the code that throws the exception in the first place. — Louis Wasserman, Sep 11 '15 at 21:13
Catching an exception prevents it from propagating further. You can `throw` the same exception again to send it onward, but that clobbers the stack trace. It's better to wrap the exception in a new one, and throw that. — John Bollinger, Sep 11 '15 at 21:14
@Sotirios-Delimanolis there is a way to fix this situation.. don't mark it was duplicate — Mecon, Sep 11 '15 at 21:22
Since this other code is doing a System.out, the calling method i.e. myMethod, can temporarily replace System.out with its own OutputStream. See: System.setOut() method. So, once we set our own OutputStream, we can detect if a particular message was written to that stream. — Mecon, Sep 11 '15 at 21:23
@Sotirios Delimanolis I do understand what is a duplicate.. my comment can help this user if they are really in trouble. — Mecon, Sep 11 '15 at 21:24

score 1 · Answer 1 · answered Sep 11 '15 at 21:14

A method must either handle an exception OR not handle an exception; however, that has little to do with whether it processes the exception or does some sort of exception related work.

Here is an example of a method that is aware of exceptions, but decides to delegate them to the upper call stack to be handled.

public void doSomething() throws Exception {
  try {
    some code...
  } catch (Exception t) {
    System.out.println(t.toString());
    throw t;
  }
}

public void doAndHandle() {
  try {
    doSomething();
  } catch (Exception t) {
    System.out.println(t.toString());
  }
}

Notice that I can perform processing after an exception is raised (Like I do in doSomething(), but I cannot both throw and not throw the exception. Handling an exception is a conscious decision to not throw it. Processing an exception might not fully handle it (as demonstrated in doSomething())

score 1 · Answer 2 · answered Sep 11 '15 at 21:16

As a rule, no: you cannot detect the fact that some exception has been thrown in the code that you called, as this would violate encapsulation by revealing implementation details of the API code.

One exception to this rule is that you can detect exceptions thrown by your own code called by the API as part of a callback. In this situation you could make a container shared by the callback function and the caller of the API taking the callback, and log the exceptions there.

Another exception is when the API itself offers you a channel to see exceptions, for example, by logging them through some logger framework. In this situation you could piggyback on the logging framework by providing your own "appender" that in reality does not append anything, but looks for exceptions being logged, and channels them back to your code.

score 0 · Answer 3 · answered Sep 11 '15 at 21:14

No. It is generally expected that a method will either handle any exceptions it encounters, or it will throw an exception to the calling method.

If it's neither handling the method nor throwing an exception that the calling method can handle, then this indicates a problem with the API. Because now it's likely caused your application to enter into an error state, and there's no way to detect it.

In Java, is there a way to recatch or list an exception that was previously caught

3 Answers3