What type of exception to throw in this case?

Question

I'm writing a c# application which uses automation to control another program. Naturally that program must be running for my program to work. When my program looks for the application and can't find it I'd like to throw an exception (for now later of course I could try opening the application, or telling the user to open it, or ...).

Should I implement a custom exception - or use the existing NotSupportedException (or one of the other .NET exceptions). If a custom exception, what would you suggest? I was thinking of implementing a custom exception I'd call it MyAppNameException and then just use the message to declare what the problem was?

Are there any general rules to throwing exceptions in a way that makes your program more readable and user friendly, or am I just giving this too much thought :)?

Thanks!

Oscitant

Answer 1

1. First, define MyAppCustomException as an abstract base class.

2. Then inherit from it with AppNotFoundCustomException.

This way you can catch all exceptions from your app, or just specific ones.

Here's some example code that illustrates the concept:

public abstract class MyAppCustomException : System.Exception
{
    internal MyAppCustomException(string message)
        : base(message)
    {
    }

    internal MyAppCustomException(string message, System.Exception innerException)
        : base(message,innerException)
    {            
    }
}

public class AppNotFoundCustomException : MyAppCustomException
{
    public AppNotFoundCustomException(): base("Could not find app")
    {
    }
}

And here's a client try/catch example:

try 
{
   // Do Stuff
}
catch(AppNotFoundCustomException)
{
   // We know how to handle this
}
catch(MyAppCustomException) // base class
{
   // we don't know how to handle this, but we know it's a problem with our app
}

Salman

When deriving from System.Exception, it is good practice to implement the three recommended common constructors. That said, in the situation described in the question, throwing an exception may not be the best approach. See the answer by @Hans Passant. – Bik

Answer 2

The Framework Guidelines book that I use indicates that you should only create a custom exception when the error condition can be programmatically handled in a different way than any existing exceptions.

In your case, if you wanted to create a custom exception in order to launch a back-end installation program, that is unique and I think a custom exception would be okay.

Otherwise, something from the System.Runtime.InteropServices.ExternalException heirarchy may be appropriate.

Pluri

+1 for only creating custom exceptions if you plan to handle them in a custom way. If you can actually do something programmaticially in the situation you've described, then I would go with what PostMan suggested. – Aeolian

Answer 3

Yeah, you're overdoing it. Nothing good is going to happen when you throw an exception, any exception, that program isn't magically going to start running when you do. Only bad things might happen, like some code actually catching that exception and trying to continue. Or nobody catching it and getting a Windows Error Report dialog. Might as well put up a message box and call it a day with Environment.Exit().

Of course, it could be more useful to the user if you actually start that program if you find it isn't running.

Castora

+1 I agree, what good is the exception really going to be in this case. It has 0 value. – Fulvous

Answer 4

You certainly shouldn't use NotSupportedException, as you suggest, because your application does support the method in question. NotSupportedException is used when a interface or abstract class is implemented, but with some members not fully implemented as they don't make sense in the context (reading from an output stream, clearing a readonly collection, etc).

A closer match is something InvalidOperationException, where a member can be used, but not given the current state.

You say "application", which suggests an executable rather than a component for use by something else. In this case you aren't going to bubble the exception up to the calling code (since there isn't calling code) but either raise a dialog (for a GUI app) or write to Console.Error (for a console app). This makes it likely that either you're just going to display the value of the Message property of the exception, or that you just need the class type to flag a particular message. Either simply deriving AppNotRunningException from Exception or just using Exception directly will probably serve perfectly well, depending on which of the two you find most convenient.

Dismast