Testing for Exceptions in Unit Tests

/// <summary>
/// My custom exception
/// </summary>
public class MyException : System.Exception
{
/// <summary>
/// Default constructor.
/// </summary>
public MyException () : base()
{
}

/// <summary>
/// Constructor accepting a string message.
/// </summary>
/// <param name="message">Exception message.</param>
public MyException (string message) : base(message)
{
}

/// <summary>
/// Constructor accepting a string message and an
/// inner exception which will be wrapped by this
/// custom exception class.
/// </summary>
/// <param name="message">Exception message.</param>
/// <param name="inner">Inner exception instance.</param>
public MyException(string message, Exception inner) : base(message, inner)
{
}

}

CindyBrucato at 2007-9-8 >

From a design perspective, you should throw ApplicationException, no Exceptions -- it's just good practice :)

However, there is definately a "bug" perse, here, because right now you can't use it for Exception, because Exception does not derive from it'sself. :) It also means the unit test framework can't catch non-CLR exceptions.

I have logged this as an issue so that we might be able to fix it for RTM.

dhoptonMSFT at 2007-9-8 >

Hello,

I just saw this as well. Dhopton, you are correct in stating that you shouldn't throw a generic exception. But I think a lot of folks think that if you give throw with a new message string in the exception, that will make the exception different enough.

So, did this feature get into the final release? It doesn't look like it. I am useing the VS demo build, 50727.42 and I am seeing the same error message from the unit test, " has invalid ExpectedException attribute. The type must inherit from Exception."

Do you know if they will add this in a patch?

Thanks Dan!

snotman at 2007-9-8 >