What's the best way to handle exceptions over the lifetime of your code?

Question

When I'm writing a function in a utility module to be used again, I tend to leave lots of comments at the top of functions and some simple input checks to throw up a message in the debugger if a function is used inappropriately, w/o simply using a throw command.

What's the best methodology of handling such situations? What functionality is easiest to use for this in C#?

In my CS classes a decade ago, we would simply use an assert(...) command in C++ and let the program bomb out if something was used incorrectly.

Now that I'm using C# I've used two methods, throwing up a MessageBox.Show("...") to clarify why a function is returning prematurely or a Console.WriteLine("...") to have it explained only in the debug console.

I'm currently leaning toward writing a custom ErrorMessage fuction that would check the build type and possibly a #define master toggle before displaying anything and probably saving to a .log file if I'm in a beta environment.

What's the best method to use in such utility modules?

Answer 1

Throw an exception. It's the clearest way of indicating that something's wrong, and it's much harder to ignore than a console message or even a message box.

In particular, it means that that code path won't keep going, assuming that everything's fine. Even if the user (whether in beta or not) notices the message box, they're not going to be happy to find out that as soon as they click on "OK" the application goes ahead and wipes their data out just because the utility method wasn't used properly.

Answer 2

If the method is being called with invalid arguments then it should throw an ArgumentException, or an exception derived from it. If the method is being called that cannot be called currently due to the state of the object then it should throw an InvalidOperationException.

Other people calling your library will not thank you for doing things in a non-standard or a non-obvious manner. Such as showing message boxes. Especially if they are calling your library from a web site or a windows service that can't display UI. And outputting to the debug window is far too likely to get missed.

Answer 3

I agree with Jon's answer, but you also have Debug.Assert as part of your toolkit. Sometimes this can serve you better if you want to warn developers of something, but want it to slide through in production code.

Answer 4

I like pipTheGeek's answer, but I thought I'd throw in a plug for an MSR technology that may be in the pipeline for C# 4.0: Code Contracts

The obvious answer is to use the standard exceptions that come packaged in the .Net base-class libraries(ArgumentNullException, InvalidOperationException, NotImplementedException etc), or invent your own specific exception if you feel that a consumer of your class might need to know a bit more detail about why they're receiving an exception.

If your code is going to be used later, be sure to list the possible exceptions in the Xml comments section.

Stack information is filled in on your behalf by the CLR, so all you need to do is throw that bad-boy and let the consumer deal with the consequences.

Since you asked about the syntax:

    /// <summary>
    /// Summary: 
    ///     Does stuff.
    /// Exceptions:
    ///     ArgumentNullException:
    ///        args must be non-null
    /// </summary>
    /// <param name="args"></param>
    public static void DoStuff(string[] args)
    {
        if(args == null)
        throw new ArgumentNullException("args", "'args' parameter cannot be null.");

        ...
    }