Comments on: The TryThis method

By: Scott Koon

Scott Koon — Thu, 27 Aug 2009 16:16:15 +0000

Yeah, we do something like this:

protected T WrapWithStandardExceptionHandling(int eventLogId, Func func)
{
try
{
var result = func();
return result;
}
catch (Exception e)
{
if (!(typeof(BaseException).IsAssignableFrom(e.GetType())))
{
Log.Instance.LogError(eventLogId, e);
}
throw;
}
}

By: Mike

Mike — Thu, 27 Aug 2009 14:32:23 +0000

For this cross-cutting code I tend to use AOP using Castle Windsor for instance by convention all public methods on my controllers will have an interceptor assigned to them to handle logging of any unhandled exceptions http://code.google.com/p/issuetrackerdotnet/source/browse/trunk/src/IssueTracker.Controllers/ExceptionLoggingInterceptor.cs

This way your code does not need to change at all no lamdas needed!

By: jcteague

jcteague — Thu, 27 Aug 2009 14:06:55 +0000

@pablo
I don’t test private methods directly, I just put the method in my test class for the purpose of this demonstration.

Usually I’ll will test the public methods that call the private method and make sure I get all of the paths with NCover.

You can test protected methods by creating a test double. I’ll do a post about that tonight.

By: jcteague

jcteague — Thu, 27 Aug 2009 14:03:58 +0000

@Micheal, @Nick
I don’t use production code in my blog posts. I’m trying to illustrate how you can use delegates to clean up you code. In reality I am catching a specific exception. As some of the other commenters have mentioned, if you want something more generic there are ways.

@David, I started with a Func paramter, but because of the different number of input paramters didn’t work very well. That’s why I encapsulated it in a action where I can handle any number of paramters, different output parameters easily.

@Tuna, I like that. I thought about doing something a little more fluentish. Maybe next time.

By: Scott Koon

Scott Koon — Thu, 27 Aug 2009 12:39:07 +0000

We use a similar method called WrapWithStandardExceptionHandling in our service layer, but we use it in a lambda. I can’t remember the specific implementation details right now though, it’s 5 AM here, I’ll look at it at work and see if it might have the same effect.

By: David Thibault

David Thibault — Thu, 27 Aug 2009 12:17:09 +0000

Nice idea. Also :

public static class Try {
public static bool This< T >(Func< T > block, out T result) {
try {
result = block();
return true;
}
catch (Exception) {
result = default(T);
return true;
}
}
}

And then :

int result;
if (Try.This(() => MightGoWrong(), out result)) {
// it worked and we have the result
}

By: pablo

pablo — Thu, 27 Aug 2009 09:30:16 +0000

My tests are always located in a separated project that contains ONLY the NUnit test classes.

The problem that I’m facing with it is that I cannot test protected/private methods.

How would you test your protected/private methods?

By: Tuna Toksoz

Tuna Toksoz — Thu, 27 Aug 2009 09:22:10 +0000

My favorite is:

Try.Something(()=>doexceptionalthinghere())
.Catch(x=>dosomethingwithx)

i don’t use this at all, but like it anyway

By: Nick

Nick — Thu, 27 Aug 2009 08:40:38 +0000

This seems like a good solution to check that *an* exception has been thrown. The only problem is that if you want to be testing your exceptional cases to see what type of exception it was or what the message was, you can’t do it with this.

By: Tim Van Wassenhove

Tim Van Wassenhove — Thu, 27 Aug 2009 07:00:20 +0000

In most use-cases i would want to have more control about the type of exceptions that are swallowed… Probably something like:

private bool TryThis(Action block, Func exceptionHandler)
{
try
{
block();
return true;
}
catch(Exception ex)
{
if(!exceptionHandler(ex)) throw;
return false;
}
}