I am creating an interface and would like the implementer(s) of this interface to throw exceptions in the case that something goes wrong. Let's call the implementer a plugin. I have a director which can call any one of the plugins. Rather than each plugin throwing it's own random exception, I would like plugins to throw specific exceptions which my director can then handle. For example: If the plugins fail to authenticate with the credentials that are provided by the director or if the requested action times out on the plugin, the plugin should throw an exception. Rather than each plugin throw it's own random exception, I would like plugins to throw specific exceptions that the director knows about and can handle. I do this because if an exception is fatal (like authentication failed) I don't want to retry, whereas if it was a timeout, the director may decide to retry.

Now, I am confused as to which of the following ways is better:

Idea 1:

Create a custom exception (lets say PluginException) and have an enum type which different types of exception (such as authenticationfailed, timeoutout, permissiondenied, etc.) The director will catch all PluginExceptions and handle each exception case by case.

Idea 2:

Create an abstract exception (lets say PluginException again) and have specific exception types derive from my abstract exception (like AuthenticationFailedException, TimeoutException, etc.) The director can listen for any specific exception it is interested in and also listen for the broader PluginException if none of the above exception types match the exception thrown by the plugins.

1 Answer 1


The main problem you'll have here is that C# has no way of enforcing your exception types among implementers.

The bigger problem for me is that this implies that your plugins are very closely coupled to your director. I would normally expect a simple API for communication between the plugin and director. Then too, this custom exception could run code when thrown, which to my naive sensitivities would appear to be a potential security threat.

Ultimately, I'd say that timeouts and authentication issues are owned by the code that attempts them. You don't trust a plugin to tell you it's authentication failed, you simply fail to authenticate the plugin. If a plugin times out, it lies on the implementer to solve it. I find it likely that you do not want or need this kind of crosstalk in your application.

  • My director needs to know if there was an authentication problem (fatal) or a timeout (non-fatal) because based on the type of exception it needs to decide further actions. For example: if it was an authentication problem director needs to stop further communication with the plugin until the authentication problem is resolved. Also based on the exception, director will have to inform the appropriate admin to look at the issue.
    – Yogesh
    Jul 30, 2014 at 13:25
  • 2
    You're looking at this from the wrong direction, I think. Exceptions are for exceptional situations, things that should usually result in a crash. They are not equivalent to events you want to handle. Why is there authentication happening in a plugin? Is it connecting to a database? Then it's the plugin's issue to solve, not the director's. If it's to determine whether or not the plugin is authentic, that is the director's job. Timeouts are the same thing. Ultimately, you need to send a message back with a result, but if it's one you never want to result in a crash, it's not an exception.
    – Magus
    Jul 30, 2014 at 14:27
  • "Inherit from Abstract Class" but we're discussing interface, i.e. the C# keyword yes? So why not a templated abstract class? The virtual methods are called within the abstract "code framework" and give the Director context for knowing what exception to throw. You may have to design a ReturnResult class so the communication is rich enough to make intelligent decisions; that is to say, object oriented. This does not have to conflict with @Magus comment, that I up-voted.
    – radarbob
    Aug 11, 2014 at 23:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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