¿Las instrucciones try-catch de anidamiento siguen oliendo a código si se anidan dentro de un bucle?

He oído que las declaraciones de anidación try-catch a menudo pueden ser un olor a código, por lo que me pregunto si esta situación es una excepción. Si no, ¿cuáles serían algunas buenas maneras de refactorizar?

Mi código tiene el siguiente aspecto:

try{
    X x = blah;
    otherStuff;
    for (int i = 0; i < N; i++){
        try{
            String y = Integer.toString(i);
            f(x);
        }
        catch(Exceptions1 e1){
            System.err.println(... + y + ...);
            System.exit(0);
        }
}
catch(Exceptions2 e2){
    ...
}

Estoy usando Exceptionsaquí para indicar una captura múltiple.

e2se utiliza para detectar excepciones lanzadas al inicializar xy hacer otherStuff. Lo ideal sería que mi try-catch rodeara solo esas dos líneas, pero lo uso xdentro de mi bucle y quería evitar las advertencias de "asignación no utilizada" causadas por la inicialización a nulo fuera del try-catch.

e1no fue capturado de forma múltiple e2porque quiero proporcionar al usuario información sobre los detalles de iteración y, por lo tanto, quería un bloque catch dentro del ciclo.

Si la e2captura es, como usted dice, solo para detectar errores al inicializar xy hacer otherStuff, podría extraerla a un método separado. Esto también separa muy bien la lógica y le permite potencialmente darle un nombre significativo otherStuff.

public X Foo() {
    try{
        X x = blah;
        otherStuff;

        return x;
    }
    catch(Exceptions2 e2){
        ...
    }
}

public void Bar() {    
    X x = Foo();
    for (int i = 0; i < N; i++){
        try{
            String y = Integer.toString(i);
            f(x);
        }
        catch(Exceptions1 e1){
            System.err.println(... + y + ...);
            System.exit(0);
        }
    }
}

A menos que tenga la intención de procesar todo el ciclo interno, ya sea que ocurra una excepción o no, su código es esencialmente equivalente a

try{
    X x = blah;
    otherStuff;
    for (...){ 
       f(x)
    }
}
catch(Exceptions1 e1){
    ...
}
catch(Exceptions2 e2){
    ...
}

que no requiere anidamiento.

Si aún necesita el manejo de excepciones internas, refactorice la excepción interna y su método de inclusión en un nuevo método. Esto también tiene el beneficio adicional de obligarlo a pensar en otras formas de procesar el ciclo interno; Las excepciones pueden volverse muy caras en términos de rendimiento, si se lanzan muchas de ellas.

Tengo algunas observaciones sobre tu pregunta:

1. En el ejemplo que proporcionó, no necesita excepciones en absoluto. Solo necesitaría verificar la cadena y, registrar cualquier error y salir del bucle. Nada es excepcional acerca de que sea inválido y necesite registrarse. El hecho de que esté utilizando excepciones en este caso es una indicación de olor a código.

2. Las excepciones de captura múltiple no están destinadas realmente a usarse para envolver grandes extensiones de código y atrapar cualquier cosa que pueda salir mal. Su objetivo es ayudar a distinguir entre excepciones en el caso en que una sola sección de código puede producir una serie de excepciones diferentes. Como está utilizando las excepciones de captura múltiple como una especie de enfoque de "capturar todo", esto indica olor a código.

3. No tiene ningún sentido poner una prueba try dentro del ciclo a menos que planee continuar iterando por el resto del ciclo incluso si se encuentra una excepción en uno de los elementos. Su código de muestra muestra que planea salir del ciclo si alguno de los elementos es excepcional.

Creo que podrías estar mejor con algo como:

try
{
     var x = blah;
     DoStuff();
     foreach(var i in icollection) // i is an int
     {
          var y = SomethingDependentOnI(i);

          // check y for explicit exceptional states
          if (IsSomethingWrongWithY(y))
               throw new Exception1(y);
     }
}
catch (Exception1 e1)
{
}
catch (Exception2 e2)
{
}

Esto es mucho más claro, pero aún sufre los problemas descritos anteriormente.