Should event handlers in C# ever raise exceptions?

Throwing an exception from a event handler is in many ways similar to throwing an exception from a IDisposable.Dispose method (or a C++ destructor). Doing so creates havoc for your caller because you leave them with little option.

  1. Ignore the exception and let it propagate. This breaks their contract to inform all listeners of an event. This is a very real problem if anyone above them on the stack catches the exception.
  2. Catch it call the other handlers and rethrow. But what happens if one of the others throw as well?
  3. Swallow the exception. This is just bad in general. Event sources should have no knowledge of their caller and hence can’t know what they’re swallowing.
  4. Crash the process because you’re toast.

Of all of these #4 is the best option. But this is rarely done and can’t be counted on.

I think in your component you really only have a few options

  • You are calling the code which is throwing and are in the best position to handle the exception. If it’s not handleable by you then it’s unreasonable to expect it to be handled by anyone else. Hence crash the process and be done with it.
  • Don’t call the API which throws

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)