116

Consider a situation where I have three (or more) ways of performing a calculation, each of which can fail with an exception. In order to attempt each calculation until we find one that succeeds, I have been doing the following:

double val;

try { val = calc1(); }
catch (Calc1Exception e1)
{ 
    try { val = calc2(); }
    catch (Calc2Exception e2)
    {
        try { val = calc3(); }
        catch (Calc3Exception e3)
        {
            throw new NoCalcsWorkedException();
        }
    }
}

Is there any accepted pattern which achieves this in a nicer way? Of course I could wrap each calculation in a helper method which returns null on failure, and then just use the ?? operator, but is there a way of doing this more generally (i.e. without having to write a helper method for each method I want to use)? I've thought about writing a static method using generics which wraps any given method in a try/catch and returns null on failure, but I'm not sure how I would go about this. Any ideas?

aculich
  • 14,545
  • 9
  • 64
  • 71
jjoelson
  • 5,771
  • 5
  • 31
  • 51
  • Can you include some details about the calculation? – James Johnson Oct 17 '11 at 16:07
  • 2
    They're basically just different methods of solving/approximating a PDE. They're from a 3rd party library, so I can't alter them to return error codes or null. The best I could do is wrap each one individually in a method. – jjoelson Oct 17 '11 at 16:09
  • Are the calc methods part of your project (instead of a third party library)? If so, you could pull out the logic that throws exceptions and use that to decide which calc method needs to be called. – Chris Oct 17 '11 at 16:11
  • 1
    There is another use-case for this that I have come across in Java -- I need to parse a `String` to a `Date` using `SimpleDateFormat.parse` and I need to try several different formats in order, moving on to next when one throws exception. – Miserable Variable Oct 20 '11 at 12:39

16 Answers16

127

As far as possible, don't use exceptions for control flow or unexceptional circumstances.

But to answer your question directly (assuming all the exception-types are the same):

Func<double>[] calcs = { calc1, calc2, calc3 };

foreach(var calc in calcs)
{
   try { return calc(); }
   catch (CalcException){  }
} 

throw new NoCalcsWorkedException();
Ani
  • 111,048
  • 26
  • 262
  • 307
  • 16
    This assumes that `Calc1Exception`, `Calc2Exception`, and `Calc3Exception` share a common base class. – Wyzard Oct 17 '11 at 16:18
  • This works nicely. There actually is a common base exception for the calcs (which I should have mentioned), so I don't even have to `catch (Exception)` – jjoelson Oct 17 '11 at 16:28
  • 3
    On top, he assumes a common signature - which is not really that far off. Good answwer. – TomTom Oct 17 '11 at 16:41
  • 1
    Also, I added `continue` in the catch block and `break` after the catch block so that the loop ends when a calculation works (thanks to Lirik for this bit) – jjoelson Oct 17 '11 at 16:47
  • 6
    +1 only because it says "Don't use exceptions for control flow" although I would have used "NEVER EVER" instead of "As far as possible". – Bill K Oct 17 '11 at 18:37
  • 1
    @jjoelson: A `break` statement following `calc();` within the `try` (and no `continue` statement at all) might be a little more idiomatic. – Adam Robinson Oct 17 '11 at 21:02
  • Is this pattern possible too in Java? – Lenar Hoyt Oct 23 '11 at 23:56
38

You could flatten out the nesting by putting it into a method like this:

private double calcStuff()
{
  try { return calc1(); }
  catch (Calc1Exception e1)
  {
    // Continue on to the code below
  }

  try { return calc2(); }
  catch (Calc2Exception e1)
  {
    // Continue on to the code below
  }

  try { return calc3(); }
  catch (Calc3Exception e1)
  {
    // Continue on to the code below
  }

  throw new NoCalcsWorkedException();
}

But I suspect the real design problem is the existence of three different methods that do essentially the same thing (from the caller's perspective) but throw different, unrelated exceptions.

This is assuming the three exceptions are unrelated. If they all have a common base class, it'd be better to use a loop with a single catch block, as Ani suggested.

Wyzard
  • 33,849
  • 3
  • 67
  • 87
  • 1
    +1: This is the cleanest, most no-nonsense solution to the problem. The other solutions I see here are just trying to be cute, IMO. As the OP said, he didn't write the API so he's stuck with the exceptions that are thrown. – Nate C-K Oct 18 '11 at 21:00
  • Yeah, sometimes the "design problem" is out of our reach. And sometimes it even comes from Microsoft. Take the `FindTimeZoneById` which is part .NET Core/Framework, it just fails with an exception if I'm passing a linux TimezoneID under Windows, then Windows timzoneId under linux, or Posix timezone under MacOS etc. have to try everything :( – Alex from Jitbit Sep 01 '21 at 15:16
38

Just to offer an "outside the box" alternative, how about a recursive function...

//Calling Code
double result = DoCalc();

double DoCalc(int c = 1)
{
   try{
      switch(c){
         case 1: return Calc1();
         case 2: return Calc2();
         case 3: return Calc3();
         default: return CalcDefault();  //default should not be one of the Calcs - infinite loop
      }
   }
   catch{
      return DoCalc(++c);
   }
}

NOTE: I am by no means saying that this is the best way to get the job done, just a different way

musefan
  • 47,875
  • 21
  • 135
  • 185
  • 6
    I had to implement "On Error Resume Next" in a language once, and the code I generated looked a lot like this. – Jacob Krall Oct 17 '11 at 16:21
  • 4
    Please don't ever use a switch statement to create a for loop. – Jeff Ferland Oct 17 '11 at 19:33
  • 3
    It is not maintainable to have switch statement for looping – Mohamed Abed Oct 17 '11 at 19:49
  • 1
    I know my answer is not the most efficient code, but then again using try/catch blocks for this kind of thing is not the best way to go anyway. Unfortunately, the OP is using a 3rd party library and has to do the best they can to ensure success. Ideally, the input could by validated first and the correct calculation function chosen to ensure it will not fail - of course, you could then put all that in a try/catch just to be safe ;) – musefan Oct 19 '11 at 08:28
  • 1
    `return DoCalc(c++)` is equivalent to `return DoCalc(c)` - post-incremented value won't be passed deeper. To make it work (and introduce more obscurity) it could be more like `return DoCalc((c++,c))`. – Artur Czajka Oct 22 '11 at 17:42
19

Try not to control logic based on exceptions; note also that exceptions should be thrown only in exceptional cases. Calculations in most cases should not throw exceptions unless they access external resources or parse strings or something. Anyway in the worst case follow the TryMethod style (like TryParse()) to encapsulate exception logic and make your control flow maintainable and clean:

bool TryCalculate(out double paramOut)
{
  try
  {
    // do some calculations
    return true;
  }
  catch(Exception e)
  { 
     // do some handling
    return false;
  }

}

double calcOutput;
if(!TryCalc1(inputParam, out calcOutput))
  TryCalc2(inputParam, out calcOutput);

Another variation utilizing the Try pattern and combining list of methods instead of nested if:

internal delegate bool TryCalculation(out double output);

TryCalculation[] tryCalcs = { calc1, calc2, calc3 };

double calcOutput;
foreach (var tryCalc in tryCalcs.Where(tryCalc => tryCalc(out calcOutput)))
  break;

and if the foreach is a little complicated you can make it plain:

        foreach (var tryCalc in tryCalcs)
        {
            if (tryCalc(out calcOutput)) break;
        }
Mohamed Abed
  • 5,025
  • 22
  • 31
  • Honestly, I think this just causes unnecessary abstractions. This isn't a horrible solution, but I wouldn't use this for most cases. – user606723 Oct 17 '11 at 19:33
  • If you don't care about the exception type, and you just want to handle conditional code .. thus it is definitely better in terms of abstraction and maintainability to convert it into a conditional method with return whether it is succeeded or not, this way you hide the exception handling messy syntax with a clear descriptive method .. then your code will handle it as it is a regular conditional method. – Mohamed Abed Oct 17 '11 at 19:38
  • I know the points, and they are valid. However, when using this type of abstraction (hiding messyness/complexity) almost everywhere it becomes ridiculous and understanding a piece of software for what it is becomes much more difficult. As I said, it's not a terrible solution, but I wouldn't use it lightly. – user606723 Oct 17 '11 at 19:45
9

Create a list of delegates to your calculation functions and then have a while loop to cycle through them:

List<Func<double>> calcMethods = new List<Func<double>>();

// Note: I haven't done this in a while, so I'm not sure if
// this is the correct syntax for Func delegates, but it should
// give you an idea of how to do this.
calcMethods.Add(new Func<double>(calc1));
calcMethods.Add(new Func<double>(calc2));
calcMethods.Add(new Func<double>(calc3));

double val;
for(CalcMethod calc in calcMethods)
{
    try
    {
        val = calc();
        // If you didn't catch an exception, then break out of the loop
        break;
    }
    catch(GenericCalcException e)
    {
        // Not sure what your exception would be, but catch it and continue
    }

}

return val; // are you returning the value?

That should give you a general idea of how to do it (i.e. it's not an exact solution).

Kiril
  • 39,672
  • 31
  • 167
  • 226
  • 1
    Except of course for the fact that you should normally never catch `Exception` then. ;) – DeCaf Oct 17 '11 at 16:21
  • @DeCaf as I said: that "should give you a general idea of how to do it (i.e. not an exact solution)." So the OP can catch whatever the appropriate exception happens to be... no need to catch the generic `Exception`. – Kiril Oct 17 '11 at 16:23
  • Yeah, sorry, just felt the need to get that out there. – DeCaf Oct 17 '11 at 16:24
  • 1
    @DeCaf, it's a valid clarification for those who might not be that familiar with the best practices. Thanks :) – Kiril Oct 17 '11 at 16:26
9

This looks like a job for... MONADS! Specifically, the Maybe monad. Start with the Maybe monad as described here. Then add some extension methods. I wrote these extension methods specifically for the problem as you described it. The nice thing about monads is you can write the exact extension methods needed for your situation.

public static Maybe<T> TryGet<T>(this Maybe<T> m, Func<T> getFunction)
{
    // If m has a value, just return m - we want to return the value
    // of the *first* successful TryGet.
    if (m.HasValue)
    {
        return m;
    }

    try
    {
        var value = getFunction();

        // We were able to successfully get a value. Wrap it in a Maybe
        // so that we can continue to chain.
        return value.ToMaybe();
    }
    catch
    {
        // We were unable to get a value. There's nothing else we can do.
        // Hopefully, another TryGet or ThrowIfNone will handle the None.
        return Maybe<T>.None;
    }
}

public static Maybe<T> ThrowIfNone<T>(
    this Maybe<T> m,
    Func<Exception> throwFunction)
{
    if (!m.HasValue)
    {
        // If m does not have a value by now, give up and throw.
        throw throwFunction();
    }

    // Otherwise, pass it on - someone else should unwrap the Maybe and
    // use its value.
    return m;
}

Use it like so:

[Test]
public void ThrowIfNone_ThrowsTheSpecifiedException_GivenNoSuccessfulTryGet()
{
    Assert.That(() =>
        Maybe<double>.None
            .TryGet(() => { throw new Exception(); })
            .TryGet(() => { throw new Exception(); })
            .TryGet(() => { throw new Exception(); })
            .ThrowIfNone(() => new NoCalcsWorkedException())
            .Value,
        Throws.TypeOf<NoCalcsWorkedException>());
}

[Test]
public void Value_ReturnsTheValueOfTheFirstSuccessfulTryGet()
{
    Assert.That(
        Maybe<double>.None
            .TryGet(() => { throw new Exception(); })
            .TryGet(() => 0)
            .TryGet(() => 1)
            .ThrowIfNone(() => new NoCalcsWorkedException())
            .Value,
        Is.EqualTo(0));
}

If you find yourself doing these sorts of calculations often, the maybe monad should reduce the amount of boilerplate code you have to write while increasing the readability of your code.

fre0n
  • 1,885
  • 1
  • 20
  • 26
  • 2
    I love this solution. However, it's fairly opaque to anyone who hasn't previously had exposure to monads, which means this is very far from idiomatic in c#. I wouldn't want one of my coworkers to have learn monads just to modify this one silly piece of code in the future. This is great for future reference, though. – jjoelson Oct 18 '11 at 13:03
  • 1
    +1 for sense of humor, for writing the most obtuse and verbose solution possible to this problem and then saying that it will "reduce the amount of boilerplate code you have to write while increasing the readability of your code". – Nate C-K Oct 18 '11 at 21:06
  • 1
    Hey, we don't complain about the massive amounts of code lurking in System.Linq, and happily use those monads all day. I think @fre0n just mean that if you're willing to put the Maybe monad in your toolkit, these kinds of chained evaluations become easier to look at and reason about. There are several implemntations that are easy to grab. – Sebastian Good Oct 20 '11 at 18:15
  • Just because it uses `Maybe` doesn't make this a monadic solution; it uses zero of the monadic properties of `Maybe` and so may as well just use `null`. Besides, used "monadicly" this would be the *inverse* of the `Maybe`. A real monadic solution would have to use a State monad that keeps the first non-exceptional value as its state, but that'd be overkill when normal chained evaluation works. – Dax Fohl Dec 18 '13 at 15:41
7

Another version of the try method approach. This one allows typed exceptions, since there is an exception type for each calculation:

    public bool Try<T>(Func<double> func, out double d) where T : Exception
    {
      try
      {
        d = func();
        return true;
      }
      catch (T)
      {
        d = 0;
        return false;
      }
    }

    // usage:
    double d;
    if (!Try<Calc1Exception>(() = calc1(), out d) && 
        !Try<Calc2Exception>(() = calc2(), out d) && 
        !Try<Calc3Exception>(() = calc3(), out d))

      throw new NoCalcsWorkedException();
    }
Stefan
  • 14,530
  • 4
  • 55
  • 62
4

In Perl you can do foo() or bar(), which will execute bar() if foo() fails. In C# we don't see this "if fail, then" construct, but there's an operator that we can use for this purpose: the null-coalesce operator ??, which continues only if the first part is null.

If you can change the signature of your calculations and if you either wrap their exceptions (as shown in previous posts) or rewrite them to return null instead, your code-chain becomes increasingly brief and still easy to read:

double? val = Calc1() ?? Calc2() ?? Calc3() ?? Calc4();
if(!val.HasValue) 
    throw new NoCalcsWorkedException();

I used the following replacements for your functions, which results in the value 40.40 in val.

static double? Calc1() { return null; /* failed */}
static double? Calc2() { return null; /* failed */}
static double? Calc3() { return null; /* failed */}
static double? Calc4() { return 40.40; /* success! */}

I realize that this solution won't always be applicable, but you posed a very interesting question and I believe, even though the thread is relatively old, that this is a pattern worth considering when you can make the amends.

Abel
  • 56,041
  • 24
  • 146
  • 247
  • 1
    **I just want to say "Thank you".** [I tried to implement what you were talking about](https://stackoverflow.com/a/49465494/5259296). I hope that I understood it correctly. – AlexMelw Mar 24 '18 at 14:12
3

Given that the calculation methods have the same parameterless signature, you can register them in a list, and iterate through that list and execute the methods. Probably it would be even better for you to use Func<double> meaning "a function that returns a result of type double".

using System;
using System.Collections.Generic;

namespace ConsoleApplication1
{
  class CalculationException : Exception { }
  class Program
  {
    static double Calc1() { throw new CalculationException(); }
    static double Calc2() { throw new CalculationException(); }
    static double Calc3() { return 42.0; }

    static void Main(string[] args)
    {
      var methods = new List<Func<double>> {
        new Func<double>(Calc1),
        new Func<double>(Calc2),
        new Func<double>(Calc3)
    };

    double? result = null;
    foreach (var method in methods)
    {
      try {
        result = method();
        break;
      }
      catch (CalculationException ex) {
        // handle exception
      }
     }
     Console.WriteLine(result.Value);
   }
}
Marcin Seredynski
  • 7,057
  • 3
  • 22
  • 29
3

You can use a Task/ContinueWith, and check for the exception. Here's a nice extension method to help make it pretty:

    static void Main() {
        var task = Task<double>.Factory.StartNew(Calc1)
            .OrIfException(Calc2)
            .OrIfException(Calc3)
            .OrIfException(Calc4);
        Console.WriteLine(task.Result); // shows "3" (the first one that passed)
    }

    static double Calc1() {
        throw new InvalidOperationException();
    }

    static double Calc2() {
        throw new InvalidOperationException();
    }

    static double Calc3() {
        return 3;
    }

    static double Calc4() {
        return 4;
    }
}

static class A {
    public static Task<T> OrIfException<T>(this Task<T> task, Func<T> nextOption) {
        return task.ContinueWith(t => t.Exception == null ? t.Result : nextOption(), TaskContinuationOptions.ExecuteSynchronously);
    }
}
Dax Fohl
  • 10,654
  • 6
  • 46
  • 90
1
using System;

namespace Utility
{
    /// <summary>
    /// A helper class for try-catch-related functionality
    /// </summary>
    public static class TryHelper
    {
        /// <summary>
        /// Runs each function in sequence until one throws no exceptions;
        /// if every provided function fails, the exception thrown by
        /// the final one is left unhandled
        /// </summary>
        public static void TryUntilSuccessful( params Action[] functions )
        {
            Exception exception = null;

            foreach( Action function in functions )
            {
                try
                {
                    function();
                    return;
                }
                catch( Exception e )
                {
                    exception   = e;
                }
            }

            throw exception;
        }
    }
}

And use it like so:

using Utility;

...

TryHelper.TryUntilSuccessful(
    () =>
    {
        /* some code */
    },
    () =>
    {
        /* more code */
    },
    calc1,
    calc2,
    calc3,
    () =>
    {
        throw NotImplementedException();
    },
    ...
);
Ryan Lester
  • 2,363
  • 7
  • 25
  • 38
1

It seems that the OP's intention was to find a good pattern for solving his issue and resolving the current problem that he was struggling with at that moment.

OP: "I could wrap each calculation in a helper method which returns null on failure, and then just use the ?? operator, but is there a way of doing this more generally (i.e. without having to write a helper method for each method I want to use)? I've thought about writing a static method using generics which wraps any given method in a try/catch and returns null on failure, but I'm not sure how I would go about this. Any ideas?"

I saw a lot of good patterns that avoid nested try catch blocks, posted in this feed, but didn't find a solution to the problem that is cited above. So, here is the solution:

As OP mentioned above, he wanted to make a wrapper object which returns null on failure. I would call it a pod (Exception-safe pod).

public static void Run()
{
    // The general case
    // var safePod1 = SafePod.CreateForValueTypeResult(() => CalcX(5, "abc", obj));
    // var safePod2 = SafePod.CreateForValueTypeResult(() => CalcY("abc", obj));
    // var safePod3 = SafePod.CreateForValueTypeResult(() => CalcZ());

    // If you have parameterless functions/methods, you could simplify it to:
    var safePod1 = SafePod.CreateForValueTypeResult(Calc1);
    var safePod2 = SafePod.CreateForValueTypeResult(Calc2);
    var safePod3 = SafePod.CreateForValueTypeResult(Calc3);

    var w = safePod1() ??
            safePod2() ??
            safePod3() ??
            throw new NoCalcsWorkedException(); // I've tested it on C# 7.2

    Console.Out.WriteLine($"result = {w}"); // w = 2.000001
}

private static double Calc1() => throw new Exception("Intentionally thrown exception");
private static double Calc2() => 2.000001;
private static double Calc3() => 3.000001;

But what if you'd like to create a safe pod for a Reference Type result returned by CalcN() functions/methods.

public static void Run()
{
    var safePod1 = SafePod.CreateForReferenceTypeResult(Calc1);
    var safePod2 = SafePod.CreateForReferenceTypeResult(Calc2);
    var safePod3 = SafePod.CreateForReferenceTypeResult(Calc3);

    User w = safePod1() ?? safePod2() ?? safePod3();

    if (w == null) throw new NoCalcsWorkedException();

    Console.Out.WriteLine($"The user object is {{{w}}}"); // The user object is {Name: Mike}
}

private static User Calc1() => throw new Exception("Intentionally thrown exception");
private static User Calc2() => new User { Name = "Mike" };
private static User Calc3() => new User { Name = "Alex" };

class User
{
    public string Name { get; set; }
    public override string ToString() => $"{nameof(Name)}: {Name}";
}

So, you might notice that there is no need "to write a helper method for each method you want to use".

The two types of pods (for ValueTypeResults and ReferenceTypeResults) are enough.


Here is the code of SafePod. It isn't a container though. Instead, it creates an exception-safe delegate wrapper for both ValueTypeResults and ReferenceTypeResults.

public static class SafePod
{
    public static Func<TResult?> CreateForValueTypeResult<TResult>(Func<TResult> jobUnit) where TResult : struct
    {
        Func<TResult?> wrapperFunc = () =>
        {
            try { return jobUnit.Invoke(); } catch { return null; }
        };

        return wrapperFunc;
    }

    public static Func<TResult> CreateForReferenceTypeResult<TResult>(Func<TResult> jobUnit) where TResult : class
    {
        Func<TResult> wrapperFunc = () =>
        {
            try { return jobUnit.Invoke(); } catch { return null; }
        };

        return wrapperFunc;
    }
}

That's how you can leverage the null-coalescing operator ?? combined with the power of first-class citizen entities (delegates).

AlexMelw
  • 2,406
  • 26
  • 35
1

If the actual type of the exception thrown doesn't matter, you can just use a typeless catch block:

var setters = new[] { calc1, calc2, calc3 };
bool succeeded = false;
foreach(var s in setters)
{
    try
    {
            val = s();
            succeeded = true;
            break;
    }
    catch { /* continue */ }
}
if (!suceeded) throw new NoCalcsWorkedException();
Jacob Krall
  • 28,341
  • 6
  • 66
  • 76
  • Doesn't that always call every function in the list? Might want to throw (pun not intended) in something like `if(succeeded) { break; }` post-catch. – user Oct 18 '11 at 12:51
0

You are right about wrapping each calculation but you should wrap according to the tell-don't-ask-principle.

double calc3WithConvertedException(){
    try { val = calc3(); }
    catch (Calc3Exception e3)
    {
        throw new NoCalcsWorkedException();
    }
}

double calc2DefaultingToCalc3WithConvertedException(){
    try { val = calc2(); }
    catch (Calc2Exception e2)
    {
        //defaulting to simpler method
        return calc3WithConvertedException();
    }
}


double calc1DefaultingToCalc2(){
    try { val = calc2(); }
    catch (Calc1Exception e1)
    {
        //defaulting to simpler method
        return calc2defaultingToCalc3WithConvertedException();
    }
}

The operations are simple, and can change their behaviour independently. And it doesn't matter why they default. As a prove you could implement calc1DefaultingToCalc2 as:

double calc1DefaultingToCalc2(){
    try { 
        val = calc2(); 
        if(specialValue(val)){
            val = calc2DefaultingToCalc3WithConvertedException()
        }
    }
    catch (Calc1Exception e1)
    {
        //defaulting to simpler method
        return calc2defaultingToCalc3WithConvertedException();
    }
}
raisercostin
  • 8,777
  • 5
  • 67
  • 76
-1

It sounds like your calculations have more valid information to return than just the calculation itself. Perhaps it would make more sense for them to do their own exception handling and return a "results" class that contains error information, value information, etc. Think like the AsyncResult class does following the async pattern. You can then evaluate the real result of the calculation. You can rationalize this by thinking in terms that if a calculation fails, that's just as informational as if it passes. Therefore, an exception is a piece of information, not an "error."

internal class SomeCalculationResult 
{ 
     internal double? Result { get; private set; } 
     internal Exception Exception { get; private set; }
}

...

SomeCalculationResult calcResult = Calc1();
if (!calcResult.Result.HasValue) calcResult = Calc2();
if (!calcResult.Result.HasValue) calcResult = Calc3();
if (!calcResult.Result.HasValue) throw new NoCalcsWorkedException();

// do work with calcResult.Result.Value

...

Of course, I'm wondering more about the overall architecture that you're using to get these calculations done.

Emoire
  • 49
  • 3
  • This is ok - similar to what OP suggested as far as wrapped the calculations. I'd just prefer something like `while (!calcResult.HasValue) nextCalcResult()`, instead of a list of Calc1, Calc2, Calc3 etc. – Kirk Broadhurst Oct 19 '11 at 00:56
-3

What about tracking the actions your doing...

double val;
string track = string.Empty;

try 
{ 
  track = "Calc1";
  val = calc1(); 

  track = "Calc2";
  val = calc2(); 

  track = "Calc3";
  val = calc3(); 
}
catch (Exception e3)
{
   throw new NoCalcsWorkedException( track );
}
Stefan
  • 14,530
  • 4
  • 55
  • 62
Orn Kristjansson
  • 3,435
  • 4
  • 26
  • 40
  • 4
    How does this help? if calc1() fails cals2 will never be executed! – DeCaf Oct 17 '11 at 16:12
  • this doesn't solve the problem. Only execute calc1 if calc2 fails, only execute calc3 if calc1 && calc2 fail. – Jason Oct 17 '11 at 16:15
  • +1 orn. This is what I do. I only have to code **one** catch, the message sent to me (`track` in this case), and I know **exactly** what segment in my code caused the block to fail. Maybe you should have elaborated to tell members like DeCaf that the `track` message is sent to your custom error handling routine that enables you to debug your code. Sounds like he didn't understand your logic. –  Oct 18 '11 at 17:16
  • Well, @DeCaf is correct, my code segment does not keep executing the next function which is what jjoelson asked for, there for my solution is not feasable – Orn Kristjansson Oct 18 '11 at 17:48