views:

73

answers:

3

Working on existing code, I recently found smt like this:

if(Config.ExceptionBehavior.DEBUG_EXCEPTIONS)
{
   foo.Foo();
}
else
{
   try
   {
      foo.Foo();
   }
   catch(Exception ex)
   {
      //whatever
   }
}

I am getting rid of this - but I do see some value in the driver of this kind of code: basically the guy who wrote this wanted the thing to crash on the line the exception occurred for debug purpose. At the same time this smells awfully, because you're replicating your code arbitrarily, which makes everything quite messy and littered.

Is there any decent why of obtaining similar behavior without shamelessly littering your code?

The only alternative I can think of is a bunch of #if DEBUG etc. but wondering if there is any app wide exception handling lib that can give me something like this.

Any pointers appreciated!

+2  A: 

If the point of this line is to make sure your program stops on the line throwing the exception, even if you then later on catch that exception, you can configure Visual Studio to do just that, with no changes to your code.

Here's how.

  1. Go to Debug->Exceptions
  2. Place a checkbox in the "Thrown" column for "Common Language Runtime Exceptions"
  3. Optionally, if you want finer control over which exceptions to stop on, don't place the checkbox on "Common Language Runtime Exceptions", but instead expand that node, and check those you want to stop on.

Granted, there's no way to control which source code file, namespace, project or whatnot that this setting is for, so if the code in question is throwing "Exception" or some other exception type that might get thrown a lot, then you can't use this solution, or... you could change that code.

Lasse V. Karlsen
I talked to the guy who wrote that code - basically he said he put something like this in place because he didn't want VS to stop on just any exception (as you suggest). There must be a better way of going around this!
JohnIdol
A: 

You can achieve the same thing using the Action (and Predicate) class.

public void TryIt(Action action){
    if(Config.ExceptionBehavior.DEBUG_EXCEPTIONS){
        action.Invoke();
    }else{
        try{
            action.Invoke();
        }catch{
            //whatever
        }
    }
}

public void MyMethod(string s){
   //Do something
}

public void MyOtherMethod(){
   //Do something entirely different
}

//Somewhere else in code:
TryIt(() => MyMethod("somestring"));
TryIt(MyOtherMethod);

There are also generic versions that will let you return data from the TryIt method. Please let me know if you need pointers in that direction.

klausbyskov
AOP approach is nice with regards to injecting behavior but it does not resolve the issue of replicating statements (still have action.Invoke twice)?
JohnIdol
Yes, but you only have action.Invoke twice once, if you know what I mean...
klausbyskov
A: 

I have the same problem, I think the only reliable approach is to have preprocessor directives in the topmost layer of the application (such as UI layer).

Example in a ASP.NET webpart:

   protected override void OnPreRender(EventArgs e)
    {
        base.OnPreRender(e);

        try
        {
            DoSomethingDangerous();
        }
        #if !DEBUG
        catch (Exception ex)
        {
            Utilities.HandleException(ex); // does logging & shows a pretty error msg
        }
        #endif
        finally
        {
        }
    }
driAn