0

What is the best practice for handling exceptions thrown from event handlers/listeners in a event loop? For example:

class EventLoop
{
  public:
  void start(); //create a thread which calls run();
  void run()
  {
    while(true)
    {
      listener.waitEvent();  //blocks until an event occured
      try
      {
        listener.processEvent(); //calls given handler
      }
      catch(const Exception& excp)
      {
        //The exception is thrown from another class
        //What shall I do?
      }
    }
  }
  //other code..
}
//Sample event loop usage:
EventLoop el;
SampleListener sampleListener;
el.setListener(sampleListener);
el.start();
//other work..

In this example, when processEvent() throws an exception, the event loop thread should be able to continue to run. Also, the error should be handled. One possible solution may be add an errorOccured() method to listener. In catch block the method could be invoked. But it increases complexity of the program seriously.

Your suggestions? Thanks..

  • some would just let the application crash – ratchet freak Jan 27 '15 at 11:53
4

What I do is that I just log the exception class name, the exception message, and the full exception stack trace. I do not think that there is anything else that can be done, nor anything else that needs to be done.

I consider this an integral part of the notifier pattern: the fact that an observer may fail should not affect the notifier in any way whatsoever, nor should it prevent any other observers from observing the notification.

Some people believe that once an exception has been thrown, the application should terminate, but I think that this is terribly short-sighted.

  • 1
    100% agree. If failure to process the event is significant enough to cause the system behavior to become unpredictable/corrupted then it is the observer's job to explicitly trigger appropriate actions. The observer should not just pass an exception back onto the notifier to handle. The notifier shouldn't care who is handling their event or what they do with it, let alone attempt to recover from a failure in the observer's handler. – Dunk Jan 27 '15 at 17:08
  • @Dunk OK. it's observer's responsibility to handle the error but, how can I inform the observer when an error occurred? Regarding multithreading, if I call the error handler of the observer, notifier may not process other events. Shall I create another thread for error handling? – Q Q Jan 28 '15 at 9:20
  • Huh? O_o You want to notify the listener about an error which occurred in the listener? This does not make any sense. If the listener wants to handle an error which occurred within itself, then it should have caught the exception that it generated instead of allowing it to propagate to the notifier. And what is the error handler of the observer? The observer is not supposed to have any error handler, it is supposed to just log the exception and proceed as if it did not happen. I get the feeling that you have tons of things in your mind that you did not write about in the question. – Mike Nakis Jan 28 '15 at 15:19
  • @QQ:Not sure what specifically you are thinking of. However, since the observer is the one who detected the error then it already knows about the error. The notifier doesn't call the error handler, the observer does. If the error needs to be processed in a different thread from the handler(which would have to mean the error handling is done in an already running thread) then you'll have to provide the communication mechanism. I don't know why you think you'd need to create another thread just to run the error handling unless there is a particular reason the notifier can't block for long. – Dunk Jan 28 '15 at 19:08
  • I mean the observer (listener in the example) may not caught the exception. In c++ you cannot force it to catch all exceptions. Also, the listener may not be developed as an observer. Its developer may let possible exceptions propagate. By adding an error handler method to listener interface, I can enforce error handling in observer side. It is not a best practice may be a workaround. – Q Q Jan 29 '15 at 7:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.