Pattern for trying different methods when exception is thrown

Question

Here's a question to expose my lack of experience: I have a method DoSomething() which throws an exception if it doesn't manage to do it cleanly. If it fails, I try the less accurate method DoSomethingApproximately() several times in the hope that it will find a sufficiently good solution; if this also fails I finally call DoSomethingInaccurateButGuaranteedToWork(). All three are methods belonging to this object.

Two questions: first, is this (admittedly ugly) pattern acceptable, or is there a more elegant way?

Second, what is the best way to keep track of how many times I have called DoSomethingApproximately(), given that it is likely to throw an exception? I am currently keeping a variable iNoOfAttempts in the object, and nesting try blocks... this is horrible and I am ashamed.

Answer 1

Return an error code instead of throwing an exception.

If the ways those methods fail do throw exceptions, catch them all in the same method and take appropriate action, like increasing a counter and returning an error code.

   bool result = DoSomething();
   while (!result && tries < MAX_TRIES) {
       result = DoSomethingApproximately(); //This will increment tries
       if (tries > THRESHOLD) {
           result = DoSomethingThatAlwaysWorks();
       }
   }

Answer 2

You should never use exceptions for control flow of your application.

In your case I'd bunch the three methods together into a single method and have it return which particular approach succeeded, maybe with an enum or something like that.

Answer 3

How about (pseudocode):

try{ return doSomething(); }
catch(ExpectedException) { ...not much here probably...}

for(i = 0 to RETRIES){
try{ return doSomethingApproximately; }
catch(ExpectedException) { ...not much here probably...}
}

doSomethingGuaranteed();

Addendum:

I strongly recommend that you do not use special return values, because that means that every single user of the function has to know that some of the return values are special. Depending on the range of the function, it may be sensible to return an ordinary part of the range that can be dealt with normally, e.g. an empty collection. Of course, that may make it impossible to distinguish between failure, and the "right" answer being the empty collection (in this example).

Answer 4

Go the whole function pointers in a structure route. Just to spice it up, I'll use a Queue and some LINQ.

Queue<Action> actions = new Queue<Action>(new Action[] {
   obj.DoSomething,
   obj.DoSomethingApproximately,
   obj.DoSomethingApproximately,
   obj.DoSomethingApproximately,
   obj.DoSomethingApproximately,
   obj.DoSomethingGuaranteed
});

actions.First(a => {
   try {
      a();
      return true;
   } catch (Exception) {
      return false;
   }
});