When it is best not to create user-defined exceptions?

Question

I have made a component that throws Exception. I'm thinking if I should stick with standard throw new Exception or if I should create specific exceptions.

I also consider user-defined exception as not appealing when it throws exception from Remoting or WCF. if I use standard exception, the caller can receive the exception, if I made a user-defined exception, the caller won't be able to receive the specific exception unless the component's assembly is also deployed to client; however, the client can receive the exception from user-defined exceptions if one catches the user-defined exception from within Remoting and WCF and rethrows it as standard exception, which in turn defeats the purpose of user-defined exception.

When is adding user-defined exception not so useful?

[EDIT]

Sharing my thoughts, I think user-defined exception is a must(at least one) on a component, so when you unit test your own component, you will not receive false positives.

This produces false positives:

[Test]
public void Tag_is_missing()
{

    string message = "";

    try
    {
        // Arrange  
            // this will fail on *nix systems       
        MyComponentHelper.ParseXml("C:\A.XML");
    }
    catch(Exception ex)
    {
        // Act
        message = ex.InnerException.Message;
    }


    // Assert
    // How can we be sure that the word "not found" error is from 
    // xml parsing or if from file loading? Doing Pokemon exception handling
    // will lead to ambiguities
    Assert.IsTrue(message.Contains("not found"));

}

If you didn't made your own exception, your unit test might receive false positives, the "not found" string could be from your component or from other subsystems of your component. So there goes my case of when one should create user-defined exception.

This won't produce false positives:

[Test]
public void Tag_is_missing()
{

    string message = "";

    try
    {
        // Arrange     
        // this will fail on *nix systems        
        MyComponentHelper.ParseXml("C:\A.XML");
    }
    catch(XmlParsingException ex)
    {
        // Act
        message = ex.InnerException.Message;

        // Assert
        // And now we are more sure that the error didn't come from
        // program subsystem; in particular, file subsystem.
        Assert.IsTrue(message.Contains("not found"));
    }


}

What's left to ponder is when one should create very specific user-defined exceptions. For now, I'll settle first on having just one user-defined exception for my component, unit testings should not yield false positives.

Answer 1

Use custom exceptions when you feel that the standard exceptions (provided by .NET) do not give enough information about the exception condition. In this custom exception, you could provide properties that provide more information about the exception than just the message string.

The custom exception is only a wrapper around the system exception. The original exception information is found in the InnerException property of the custom exception.

The exception class can be designed as:

public class NewException : BaseException, ISerializable
{
    public NewException()
    {
        // Add implementation.
    }
    public NewException(string message)
    {
        // Add implementation.
    }
    public NewException(string message, Exception inner)
    {
        // Add implementation.
    }

    // This constructor is needed for serialization.
   protected NewException(SerializationInfo info, StreamingContext context)
   {
        // Add implementation.
   }
}

While throwing the custom exception, use:

try
{
   .....
}
catch(ArgumentNullException argumentNullException)
{
   throw new NewException("This is a custom exception message", argumentNullException);
}

Additionally, it is recommended that you catch the base System.Exception only in the top most control class. In the inner classes you should catch the specific exception types and use custom exception if required.

For more information refer:

• http://msdn.microsoft.com/en-us/library/ms229064.aspx
• http://msdn.microsoft.com/en-us/library/ms229007.aspx
• http://msdn.microsoft.com/en-us/library/ms229021.aspx
• http://blogs.msdn.com/b/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

Answer 2

I think user-defined exceptions have only sense when this solve your problem in good way in internal project development.

Answer 3

Trapping for Exception is very generic, and could mask other unanticipated errors (as you've mentioned) by other areas of your component. Using properties or other messages is an option.

However, the approach that I've found works best is to throw one of the standard exceptions that's a subclass of Exception (eg. ArgumentOutOfRangeException); if those are not precise enough, and you need to throw something, make a subclass and throw that.

Also bear in mind that exceptions are for exceptional cases. Does it make sense to throw an exception, or would you be better served by returning some value (I don't mean an error code)?