Handling Java Exceptions Passed by Listeners

Question

Take the situation when you are writing a library for objects designed to run asynchronously. To notify the caller of the status of an asynchronous object, the caller must implement a listener interface.

Now that you are using listeners, it is likely that the listener will do something wrong, which will throw an exception for the library object.

Example

public interface SomeListener { public void progressNotification(int status); } public class SomeClass { SomeListener listener = null; … public void setListener(SomeListener listener) { this.listener = listener; } … public void someRandomMethod() { int progressStatus = 0; //Do some stuff here that updates progressStatus //then notify the caller if (listener != null) { listener.progressNotification(progressStatus); } } } public class CallerClass implements SomeListener{ public void progressNotification(int status) { //do something that will throw an exception //eg assume status is 0 int x = 200/status; //this will throw an ArithmeticException because of division by zero } } 

If SomeClass does not catch the exception and does not handle it, this will result in any code after listener.progressNotification(progressStatus); will not be executed if the object is in the "wrong" state.

So my question is: what's the best way to handle this exception in the library?

I saw one library that does this:

  if (listener != null) { try { listener.progressNotification(progressStatus); }catch (Thrwowable th) { System.err.println("An uncaught throwable " + th); } } 

which doesn't suit me.

Answer 1

For me, the listener's contract should be clearly defined:

• it should return quickly (i.e. not suspend or sleep thread, etc.),
• it should not throw an exception at runtime.

If this raises an exception at runtime, the listener violates the API contract and, therefore, is a client code error of your API, and not an error of the API itself.

I would do nothing but define and document the contract, and explain the potential impact of terminating the contract (i.e., an uncertain state, whatever). If the client really wants to protect itself from a programming error, it can still wrap all the listener code inside try / catch, as your example shows.

Answer 2

The same for everyone, we can do nothing for a RuntimeException . And that is why they are marked by uncontrolled exceptions. Read about uncontrolled exceptions is read here .

He clearly indicates this:

Runtime exceptions can occur anywhere in the program, and in a typical they can be very numerous. The need to add runtime exceptions to each method declaration will reduce program clarity . Thus, the compiler does not require you to catch or throw runtime exceptions (although you can).

So, no need to worry about it.

But, obviously, if there is any scenario, there can be any Checked exception, they must be handled properly.

In addition, it is recommended to document a possible exception that may be caused by the method.

Answer 3

If you do not want the listener to stop all notifications for everyone with bad politeness, then this exception handling is what you need to do. I have some nitpicks. Of course, I write it, not write it to stderr. And catching Throwable is not so much, there are some things (due to memory errors, on the one hand) you could also let go without selecting. But the main idea is in order.