I am working in a windows service (using VB.Net) for internal use of my department. When ever a certain type of exception (FooException for now on) is captured, I follow the same logic:Log the exceptionSend an email to someone.In order to reuse code and not to copy-paste the same lines in every catch FooException block I have created a FooExceptionHandler method inside my ExceptionHandling class. So I ended up with a code like this:FooExceptionHandler(fooException){   //log the exception   try   {      //send email   }   catch SmtpException   {      //log  the smtp exception   }}My question is about how to organize the code. Should this be a static method? Should all the exception handling class be static? Should it be a singleton? Should it be object-oriented?If the object-oriented case is the best way, should I create a new object in every catch block or is it better to have a class variable?
Exception handling class: static or object-oriented?
code organization;exception handling;language agnostic
The right answer depends on how big your application is and how you test it. If your application is big, modular enterprise application and you use unit-tests, then the only solution you really have is to go object-oriented way.In that case you create an interface IExceptionHandler, and all client classes consume that interface. You may then use some object-creation pattern like a factory method to create your exception handling objects that implement that interface, or handle it with Dependency injection.That way you make your production code decoupled from exception-handling mechanism and easily adjust or change exception-handling behaviour in future without touching the code in other classes.If your application is small and mostly for personal use, then just implement the exception-handling logic the way you feel is most convenient to you.