¿Patrón para evitar bloques de captura de prueba anidados?

Considere una situación en la que tengo tres (o más) formas de realizar un cálculo, cada una de las cuales puede fallar con una excepción. Para intentar cada cálculo hasta encontrar uno que tenga éxito, he estado haciendo lo siguiente:

double val;

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

¿Existe algún patrón aceptado que logre esto de una manera más agradable? Por supuesto, podría envolver cada cálculo en un método auxiliar que devuelve un valor nulo en caso de falla, y luego simplemente usar el ??operador, pero ¿hay alguna forma de hacer esto de manera más general (es decir, sin tener que escribir un método auxiliar para cada método que quiero usar? )? He pensado en escribir un método estático usando genéricos que envuelva cualquier método dado en un try / catch y devuelva nulo en caso de falla, pero no estoy seguro de cómo lo haría. ¿Algunas ideas?

En la medida de lo posible, no use excepciones para el flujo de control o circunstancias no excepcionales.

Pero para responder a su pregunta directamente (asumiendo que todos los tipos de excepción son los mismos):

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

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

throw new NoCalcsWorkedException();

Solo para ofrecer una alternativa "fuera de la caja", ¿qué tal una función recursiva ...

//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);
   }
}

NOTA: De ninguna manera estoy diciendo que esta sea la mejor manera de hacer el trabajo, solo de una manera diferente

Puede aplanar el anidamiento poniéndolo en un método como este:

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();
}

Pero sospecho que lo real problema diseño es la existencia de tres métodos diferentes que hacen esencialmente lo mismo (desde la perspectiva de la persona que llama) pero arrojan excepciones diferentes y no relacionadas.

Esto es asumiendo que las tres excepciones no están relacionadas. Si todos tienen una clase base común, sería mejor usar un bucle con un solo bloque de captura, como sugirió Ani.

Trate de no controlar la lógica basada en excepciones; tenga en cuenta también que las excepciones deben lanzarse sólo en casos excepcionales. En la mayoría de los casos, los cálculos no deben generar excepciones a menos que accedan a recursos externos o analicen cadenas o algo así. De todos modos, en el peor de los casos, siga el estilo TryMethod (como TryParse ()) para encapsular la lógica de excepción y hacer que su flujo de control sea mantenible y limpio:

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);

Otra variación que utiliza el patrón Try y combina la lista de métodos en lugar de anidados si:

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;

y si el foreach es un poco complicado, puedes aclararlo:

        foreach (var tryCalc in tryCalcs)
        {
            if (tryCalc(out calcOutput)) break;
        }

Cree una lista de delegados para sus funciones de cálculo y luego tenga un ciclo while para recorrerlas:

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?

Eso debería darle una idea general de cómo hacerlo (es decir, no es una solución exacta).

Esto parece un trabajo para ... ¡MONADAS! Específicamente, la mónada Quizás. Comience con la mónada Quizás como se describe aquí . Luego agregue algunos métodos de extensión. Escribí estos métodos de extensión específicamente para el problema tal como lo describiste. Lo bueno de las mónadas es que puede escribir los métodos de extensión exactos necesarios para su situación.

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;
}

Úselo así:

[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));
}

Si se encuentra haciendo este tipo de cálculos con frecuencia, la mónada quizás debería reducir la cantidad de código repetitivo que tiene que escribir mientras aumenta la legibilidad de su código.

Otra versión del enfoque del método try . Éste permite excepciones escritas, ya que hay un tipo de excepción para cada cálculo:

    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();
    }

En Perl puedes hacerlo foo() or bar(), que se ejecutará bar()si foo()falla. En C # no vemos esta construcción "si falla, entonces", pero hay un operador que podemos usar para este propósito: el operador de coalescencia nula?? , que continúa solo si la primera parte es nula.

Si puede cambiar la firma de sus cálculos y si envuelve sus excepciones (como se muestra en publicaciones anteriores) o las reescribe para regresar null, su cadena de código se vuelve cada vez más breve y aún más fácil de leer:

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

Usé los siguientes reemplazos para sus funciones, lo que da como resultado el valor 40.40en 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! */}

Me doy cuenta de que esta solución no siempre será aplicable, pero usted planteó una pregunta muy interesante y creo, aunque el hilo es relativamente antiguo, que este es un patrón que vale la pena considerar cuando pueda hacer las enmiendas.

Dado que los métodos de cálculo tienen la misma firma sin parámetros, puede registrarlos en una lista, iterar a través de esa lista y ejecutar los métodos. Probablemente sería incluso mejor para usted usar el Func<double>significado de "una función que devuelve un resultado de tipo 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);
   }
}

Puede usar Task / ContinueWith y verificar la excepción. Aquí hay un buen método de extensión para ayudar a que sea bonito:

    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);
    }
}

Si el tipo real de la excepción lanzada no importa, puede usar un bloque catch sin tipo:

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();

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;
        }
    }
}

Y úsalo así:

using Utility;

...

TryHelper.TryUntilSuccessful(
    () =>
    {
        /* some code */
    },
    () =>
    {
        /* more code */
    },
    calc1,
    calc2,
    calc3,
    () =>
    {
        throw NotImplementedException();
    },
    ...
);

Parece que la intención del OP era encontrar un buen patrón para resolver su problema y resolver el problema actual con el que estaba luchando en ese momento.

OP: "Podría envolver cada cálculo en un método auxiliar que devuelve nulo en caso de falla, y luego simplemente usar el ??operador, pero ¿hay alguna forma de hacer esto de manera más general (es decir, sin tener que escribir un método auxiliar para cada método que quiero uso)? He pensado en escribir un método estático usando genéricos que envuelva cualquier método dado en un try / catch y devuelva nulo en caso de falla, pero no estoy seguro de cómo lo haría. ¿Alguna idea? "

Vi muchos patrones buenos que evitan bloques de captura de prueba anidados , publicados en esta fuente, pero no encontré una solución al problema que se cita anteriormente. Entonces, aquí está la solución:

Como OP mencionó anteriormente, quería hacer un objeto contenedor que regrese nullen caso de falla . Yo lo llamaría una cápsula ( cápsula segura para excepciones ).

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;

Pero, ¿qué sucede si desea crear un pod seguro para un resultado de Tipo de referencia devuelto por las funciones / métodos de CalcN ()?

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}";
}

Por tanto, es posible que observe que no es necesario "escribir un método auxiliar para cada método que desee utilizar" .

Los dos tipos de vainas (para ValueTypeResultsy ReferenceTypeResults) son suficientes .

Aquí está el código de SafePod. Sin embargo, no es un contenedor. En su lugar, crea un contenedor delegado seguro para excepciones tanto para ValueTypeResults como para 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;
    }
}

Así es como puede aprovechar el operador de fusión nula ??combinado con el poder de las entidades ciudadanas de primera clasedelegate .

Tiene razón acerca de ajustar cada cálculo, pero debe ajustarlo de acuerdo con el principio de decir-no-preguntar.

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();
    }
}

Las operaciones son simples y pueden cambiar su comportamiento de forma independiente. Y no importa por qué no lo hacen. Como prueba, podría implementar calc1DefaultingToCalc2 como:

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

Parece que sus cálculos tienen más información válida para devolver que solo el cálculo en sí. Quizás tendría más sentido para ellos hacer su propio manejo de excepciones y devolver una clase de "resultados" que contiene información de error, información de valor, etc. Piense como lo hace la clase AsyncResult siguiendo el patrón asíncrono. A continuación, puede evaluar el resultado real del cálculo. Puede racionalizar esto pensando en términos de que si un cálculo falla, es tan informativo como si pasara. Por lo tanto, una excepción es un dato, no un "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

...

Por supuesto, me pregunto más sobre la arquitectura general que está utilizando para realizar estos cálculos.

¿Qué pasa con el seguimiento de las acciones que está haciendo ...

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 );
}