What are industry standard best practices for implementing custom exceptions in C#?

小开

I assume you are looking for exception handling practices. So have look on following articles,

http://msdn.microsoft.com/en-us/library/ms229014.aspx //gives overall ideas about exceptions including custom exceptions

http://blogs.msdn.com/b/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx //

小开

最佳答案

The standard for creating custom exceptions is to derive from Exception. You can then introduce your own properties/methods and overloaded constructors (if applicable).

Here is a basic example of a custom ConnectionFailedException which takes in an extra parameter which is specific to the type of exception.

[Serializable]
public class ConnectionFailedException : Exception
{
public ConnectionFailedException(string message, string connectionString)
: base(message)
{
ConnectionString = connectionString;
}


public string ConnectionString { get; private set; }
}

In the application this could be used in scenarios where the application is attempting to connect to a database e.g.

try
{
ConnectToDb(AConnString);
}
catch (Exception ex)
{
throw new ConnectionFailedException(ex.Message, AConnString);
}

It's up to you to then handle the ConnectionFailedException at a higher level (if applicable)

Also have a look at Designing Custom Exceptions and Custom Exceptions

小开

Here is the code to create a custom exception:

using System;
using System.Runtime.Serialization;


namespace YourNamespaceHere
{
[Serializable()]
public class YourCustomException : Exception, ISerializable
{
public YourCustomException() : base() { }
public YourCustomException(string message) : base(message) { }
public YourCustomException(string message, System.Exception inner) : base(message, inner) { }
public YourCustomException(SerializationInfo info, StreamingContext context) : base(info, context) { }
}
}

小开

I use Custom Exceptions to communicate the nature of the error.

For example, I like using the framework provided "ArgumentNullException" to check arguments. Then later, when I see this error either in the debugger, or in an error log, I immediately know the nature of the error without reading any further.

The other end of the spectrum is the InvalidOperationException which could mean pretty much anything.

The alternative to custom exceptions is detailed error messages. That's ok, but by making a custom exception such as ConnectionFailed is more meaningful. Then the message itself can give greater details.

When creating such custom exceptions, I do not add any new properties. The reason for this is that if you have an error logger, you want it to work on all exceptions. If you add a special property, then the error logger is going to ignore it. For example, if you use MSTest, when you run your test and it fails, the custom properties are not displayed. But if you stick with the Message property of the baseclass, it will display just fine.

So the subclassing is very simple:

public class NavigationException : Exception{
public NavigationException() {}
public NavigationException(string msg) : base(msg) {}
public NavigationException(string msg, Exception inner) : base(msg, inner) {}
}

This is very straightforward, works with any error logger, and when I see it, I know it was a Navigation problem and I can view the details if needed.

Greg