Develop Reference

Testing for exceptions and catch exception details

I've looked at other post concerning unit testing but none that I saw actually test what's in the exception when thrown. The main goal is to raise an exception and examine the details of the stack trace by sending a bad parameter to a helper class.
Since the original code wasn't throwing an exception I decided to do some online research on NUnit testing and come across a very nice piece of code that is lot shorter then what I wrote but failes to examine the error object. I need to be able to Assert a presence of certain verbiage in the stack trace.
Originally this is what the code looked like, but I must admit it is not very pretty:
[Test]
public void TestExceptionHandling()
{
try
{
DoExceptionScenario(new SomeCustomRadioButtonControl(), FieldManager.GetField("access_mode"));
}
catch (Exception ex)
{
Assert.IsInstanceOf(typeof(CustomException), ex);
string details = Util.GetExceptionDetails((CustomException)ex);
Assert.IsTrue(details.Contains("Detail Name=\"ControlName\" Description=\"SomeCustomRadioButtonControl\""));
}
}
The problem as you may see is a possiblity of bunch of false positives.
The other way I modified the test is like this:
[Test]
public void TestExceptionHandling()
{
Assert.That(() => DoExceptionScenario(new SomeCustomRadioButtonControl(), FieldManager.GetField("access_mode")),
Throws.TypeOf<CustomException>());
}
This will fail if there is no exception. But if there is an exception how do I capture that and examine its contents? Something along lines of (the if statement would work in this case):
[Test]
public void ShouldControlNameBeListedInStackTrace()
{
bool exceptionStatus = Assert.That(() => DoExceptionScenario(new SomeCustomRadioButtonControl(), FieldManager.GetField("access_mode")),
Throws.TypeOf<CustomException>());
if (exceptionStatus != true)
{
string details = Util.GetExceptionDetails((CustomException)ex);
Assert.IsTrue(details.Contains("detail name=\"controlname\" description=\"SomeCustomRadioButtonControl\""));
}
}

Assume a CustomException class that looks like this. It doesn't do much of anything... just overrides the "Message" property from the base Exception class:
public class CustomException : Exception
{
private string message;
public override string Message
{
get { return string.Format("{0}: {1}", DateTime.Now, message); }
}
public CustomException(string message)
{
this.message = message;
}
}
And assume you have a method that throws the exception, such as this:
public class ProductionClass
{
public void SomeMethod()
{
throw new CustomException("Oh noz!");
}
}
Here's a few sample tests you can use in nUnit. You want the last one.
[TestFixture]
public class MyTests
{
private ProductionClass p;
[SetUp]
public void Setup()
{
p = new ProductionClass();
}
// Use the ExpectedException attribute to make sure it threw.
[Test]
[ExpectedException(typeof(CustomException)]
public void Test1()
{
p.SomeMethod();
}
// Set the ExpectedMessage param to test for a specific message.
[Test]
[ExpectedException(typeof(CustomException), ExpectedMessage = "Oh nozzzz!")]
public void Test2()
{
p.SomeMethod();
}
// For even more detail, like inspecting the Stack Trace, use Assert.Throws<T>.
[Test]
public void Test3()
{
var ex = Assert.Throws<CustomException>(() => p.SomeMethod());
Assert.IsTrue(ex.StackTrace.Contains("Some expected text"));
}
}
The Assert.Throws<T> method works with any Exception. It executes the delegate in the parentheses and detects whether or not it threw the exception.
In the above test, if it did throw, it then tests the stack trace for the specified contents too. If both steps pass, the test passes.

Catching base but not sub exceptions

I am writing a HttpHandler and as part of my internal design, I throw different exceptions and catch them at the top level in order to determine what status code to set the request to.
I.e.
ArgumentException triggers Bad Request
AuthenticationException triggers Unauthorised
OracleException triggers InternalServerError
etc
The problem I've found is that I was using InvalidOperationException to trigger NotFound, but a bug in my code caused me to realise that, of course, some system exceptions inherit from these base system exceptions, which causes unexpected responses.
I.e. I found that ObjectDisposedException inherits from InvalidOperationException, which means that the response returns a 404 instead of 500.
Is there a way to catch just the base exception?
I found this thread which suggests I could do a filter and rethrow, but that seems hacky.
Would I be better off just creating my own exception types to save all this hassle?

If you only want to pass the HTTP result code (and maybe error message line) to the client, then I recommend you create a single custom exception:
public class MyCustomException : Exception { // Or maybe InvalidOperationException
public int StatusCode {get;set;}
public string Status {get;set;}
}
etc.

As far as I am aware there's no way to catch an exception but not catch inherited exceptions. The problem is that you're considering the base exception to be more specific than the inherited exception, which is the opposite of how they're intended to work (Inherited exceptions should be more specific subsets of their parent, so conceptually if you can handle the parent you should be able to handle the inherited exception).
Your options basically are:
Create your own exception type & only catch this. If your exception falls under the definition of an InvalidOperationException then you can inherit from this. Then you can catch yours specifically.
Catch, inspect, and re-throw if it's not what you're after. This technique I typically try to avoid but is sometimes required if exception types are too generic. e.g.
catch (InvalidOperationException ex) {
if (ex.GetType() != typeof(InvalidOperationException)) throw;
/* Do stuff */
}

It is not possible to only catch base exceptions.
In this case it is best to create a custom exception, rather than use the system's exception types.
public class HttpErrorException : Exception
{
public HttpStatusCode StatusCode { get; private set; }
public HttpErrorException(HttpStatusCode code, string message)
: base(message)
{
this.StatusCode = code;
}
}
throw new HttpErrorException(400, "You sent a bad request!");
If the original intention was to obfuscate the HTTP status codes, and instead use their text names, factory methods can be created.
public class HttpErrorException : Exception
{
public HttpStatusCode StatusCode { get; private set; }
private HttpErrorException(HttpStatusCode code, string message)
: base(message)
{
this.StatusCode = code;
}
public static HttpErrorException BadRequest(string message)
{
return new HttpErrorException(400, message);
}
public static HttpErrorException InternalServerError(string message)
{
return new HttpErrorException(500, message);
}
// etc
}
throw HttpErrorException.BadRequest("You made a bad request!");

Multicast OnExceptionAspect is logging bubbling exceptions

I have a multicast OnExceptionAspect from Postsharp which is applied on the assembly level. This naturally means that all methods, upon throwing an exception, will invoke the Aspect.
Within the Aspect I'm logging the exception details including the values of the parameters passed when the exception occured, this is working properly.
However because this is applied to all methods in the assembly a log entry is created for each method in the stack as the exception bubbles up through each.
I'm out of ideas on how to prevent this, initially I was going to compare the exception (to see if it's the same one) but this just seems messy. Someone must have had this problem before, any ideas?

There are two solutions to this problem.
A. Use a thread-static field to store any exception that has already been logged.
[Serializable]
public class MyAspect : OnExceptionAspect
{
[ThreadStatic]
private static Exception lastException;
public override void OnException(MethodExecutionArgs args)
{
if(args.Exception != lastException)
{
string msg = string.Format("{0} had an error # {1}: {2}\n{3}",
args.Method.Name, DateTime.Now,
args.Exception.Message, args.Exception.StackTrace);
Trace.WriteLine(msg);
lastException = args.Exception;
}
}
}
B. Add a tag to the Exception object.
[Serializable]
public class MyAspect : OnExceptionAspect
{
private static object marker = new object();
public override void OnException(MethodExecutionArgs args)
{
if(!args.Exception.Data.Contains(marker))
{
string msg = string.Format("{0} had an error # {1}: {2}\n{3}",
args.Method.Name, DateTime.Now,
args.Exception.Message, args.Exception.StackTrace);
Trace.WriteLine(msg);
args.Exception.Data.Add(marker, marker);
}
}
}

FYI--Gael is a PostSharp guru because he is employed there...just so you are aware.
For what it is worth you can always tell where the exception originated by examining the StackTrace. The StackTrace is made available via args.Exception.StackTrace. You may try what Dustin Davis (another PostSharp employee) recommends here: PostSharp - OnExceptionAspect - Get line number of exception
Parse the StackTrace (via the method outlined here: How to split a stacktrace line into namespace, class, method file and line number?) then compare the args.Method.Name with the parsed results. If your args.Method.Name is the same as the originating method (found via parsing the StackTrace) then you know you should log it otherwise ignore.
Here is some code to make my solution more concrete (building on the prior two solutions cited):
[Serializable]
public class ExceptionWrapper : OnExceptionAspect
{
public override void OnException(MethodExecutionArgs args)
{
var st = new StackTrace(args.Exception, true);
var frame = st.GetFrame(0);
var lineNumber = frame.GetFileLineNumber();
var methodName = frame.GetMethod().Name;
if(methodName.Equals(args.Method.Name))
{
string msg = string.Format("{0} had an error # {1}: {2}\n{3}",
args.Method.Name, DateTime.Now,
args.Exception.Message, args.Exception.StackTrace);
Trace.WriteLine(msg);
}
}
}
(Or, honestly, you could just use one of Gael's recommended solutions.)

One way i could see this being done would be to define a custom exception and just throw that one in your aspect. then also in your aspect check the exception before loggin, if it's not your custom exception log it, otherwise don't log it and (re-throw?).
That's what the example code would look like:
[Serializable]
public class DatabaseExceptionWrapper : OnExceptionAspect
{
public override void OnException(MethodExecutionArgs args)
{
if(!(args.Exception is CustomException))
{
string msg = string.Format("{0} had an error # {1}: {2}\n{3}",
args.Method.Name, DateTime.Now,
args.Exception.Message, args.Exception.StackTrace);
Trace.WriteLine(msg);
}
throw new CustomException("There was a problem");
}
}
Of course you'd still have to define that exception and everything. :)

Exceptions - Differentiating Exceptions when method raises more than one

I got this class which raises same type of exception, how do i capture this exception and display appropriate error message. Here is what i do now.
public bool ChangePassword(oldPassword,newPassword)
{
if(oldPassword != savedInDatabase)
{
throw new ArgumentException("Your old password is not same as one saved in our database")
}
if(string.IsNullOrEmpty(oldPassword) || string.IsNullOrEmpty(newPassword))
{
throw new ArgumentException("Your old or new password is empty of null");
}
}
and i do the below,
try
{
}
catch(ArgumentException ex)
{
if(ex.Message.contains("Your old or"))
{
messagebox.show("Either your old or new password is empty or null")
}
...
}

Your example does not really justify custom exceptions. I say just display the original message.
However, if you really want to go down the path of custom exceptions, then another option is to create a single custom exception that takes an enum with all the different options, like such:
public class PasswordException : Exception
{
public PasswordException(PasswordResult result) : base() { }
public PasswordException(PasswordResult result, string message) : base(message) { }
public PasswordException(PasswordResult result, string message, Exception innerException) : base(message, innerException) { }
}
public enum PasswordResult
{
Success = 0,
PasswordMismatch,
PasswordEmpty,
// and so forth
}

You might consider throwing different exception types. If you wished to stick with the library exception types an ArgumentNullException would be appropriate if the old or new password is null or empty. Alternatively you may consider defining your own exception types with a more specific error (perhaps similar to FaultExceptions in WCF), or including a resource identifier in your custom exception (to ensure I18N compatible):
public class ResourceableException : Exception
{
public string ResourceKey { get;set; }
}
Then used like so:
try { ... }
catch (ResourceableException e)
{
messagebox.Show(ResourceManager.GetResource(e.ResourceKey));
}

You can create custom exceptions like this:
public class PasswordEmptyOrNullException : Exception
{
public PasswordEmptyOrNullException(string message)
: base(message)
{
}
}
public class OldPasswordNotFoundException : Exception
{
public OldPasswordNotFoundException(string message)
: base(message)
{
}
}
They can then be used like this:
throw new PasswordEmptyOrNullException("A message");
Then you can handle them in a try catch statement like this:
try
{
}
catch (PasswordEmptyOrNullException ex)
{
// Do stuff
}
catch (OldPasswordNotFoundException ex)
{
// Do stuff
}
So you can handle different types of exceptions in different ways. Hope that's what you were looking for.

How to throw custom exception when exception type was passed by constructor

I've created class that takes Exception type in constructor
private readonly Exception _exception;
public StringToObject(Exception exception)
{
_exception = exception;
}
i wanted to throw exception
throw new _exception("");
but i got error:
'._exception' is a 'field' but is used like a 'type'
is any possible ways to throw it?

This is not a good practice at all. Doing so will cause you to lose your stack trace related information. Please consider reading this section of Eric Lippert's blog:
Too Much Reuse
When you write
throw new Exception();
you instantiate this new exception. But then, since your private member _exception is already instantiated, you don't need to re-instantiate it, that is instantiating an instance, which doesn't make sense. Instead, use the following:
throw _exception;
This will do it.

To rethrow an existing exception like that use
throw _exception;
However, that will modify the call stack in the exception instance, so you will lose the original source of the exception. If you want to avoid that, you can throw a new exception with the instance as an inner exception.

I'm actually very confused about why you want to do this? Are you trying to create a custom exception to provide more information? If so, then you want to use this pattern.
First define a custom exception class that derives from Exception:
public class MyCustomException : Exception // Or you could derive from ApplicationException
{
public MyCustomException(string msg, Exception innerException)
: base(msg, innerException)
{
}
}
You could also define additional parameters in your custom exception constructor to contain even more information if you wish. Then, in your application code...
public void SomeMethod()
{
try
{
// Some code that might throw an exception
}
catch (Exception ex)
{
throw new MyCustomException("Additional error information", ex);
}
}
You'll want to be sure to keep track of the inner exception, because that will have the most useful call stack information about what caused the exception in the first place.

throw _exception;

This example should work. I´ve included all the classes involved in the example.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication1
{
public class MyException : Exception
{
public MyException(string message) : base(message)
{}
//...
}
public class MyClass
{
private Exception exception;
public MyClass(Exception e)
{
this.exception = e;
}
public void ThrowMyException()
{
throw exception;
}
}
class Program
{
static void Main(string[] args)
{
MyException myExceptionInstance = new MyException("A custom message");
MyClass myClassInstance = new MyClass(myExceptionInstance);
myClassInstance.ThrowMyException();
}
}
}

I suspect that what you're really looking for is to throw a new exception of your suggested type, in which case passing in a "Type" parameter (or even using a generic) would be the way forward.
However, I can't imagine a situation where this is a sensible design choice, so I'd have to urge you to reconsider (and perhaps post more of your requirements so that someone can suggest a better alternative!).