bloques try-catch con el tipo de retorno

Question

Si tengo un método que devuelve algo, como

public DataTable ReturnSomething() 
{ 
    try 
    { 
     //logic here 
    return ds.Tables[0]; 
    } 
    catch (Exception e) 
    { 
     ErrorString=e.Message; 
    } 
} 

Esto produce error de compilación, obviamente porque catch{} bloque no devuelve nada.

Así que cuando tengo métodos con valores devueltos no uso el bloque try-catch, lo cual es una mala práctica. Si hay un error, me gustaría establecer una cadena de error para ese error. Pero luego necesito un valor de retorno también. ¿Consejo?

Answer 1

tienda de su valor de retorno en una variable temporal como esto:

public DataTable ReturnSomething() 
{ 
    DataTable returnValue = null; 

    try 
    { 
     //logic here 
     returnValue = ds.Tables[0]; 
    } 
    catch (Exception e) 
    { 
     ErrorString=e.Message; 
    } 

    return returnValue; 
} 

Answer 2

Debe levantar/lanzar la excepción en su bloque catch y manejarlo en el método de llamada.

public void invokeFaultyCode() 
{ 
    try 
    { 
     DataTable dt = ReturnSomething(); 
    } 
    catch(Exception e) 
    { 
     // Print the error message, cleanup, whatever 
    }  
} 
public DataTable ReturnSomething() throws Exception 
{ 
    try 
    { 
     //logic here 
    return ds.Tables[0]; 
    } 
    catch (Exception e) 
    { 
     ErrorString=e.Message; 
     throw; 
    } 
} 

PD: Perdón por cualquier error de sintaxis, estoy un poco oxidado en C#.

Answer 3

Depende de su aplicación. Puede devolver null, un DataTable vacío o lo que sea adecuado según las circunstancias.

Answer 4

Debe encerrar a la persona que llama con una captura de prueba ... cualquier excepción que ocurra en la rutina que se llama explotará a la persona que llama y podrá atraparlos allí.

Personalmente, creo que es excesivo intentar una captura en esta rutina ya que la persona que llama debe manejar la excepción.

Para mi ejemplo, esto se codifica como sigue ...

private void DoSomething() { 
    try { 
     DataTable dt = ReturnSomething(); 
    } 
    catch (Exception ex) { 
    }  
} 

public DataTable ReturnSomething() { 
    DataTable dt = new DataTable(); 

    // logic here 
    return dt; 
} 

Answer 5

creo que el código se ejecuta en un nivel suficientemente alto de la pila de llamadas y se mezcla con el código de UI. Si este es realmente el caso, puede return null en el bloque catch. Sin embargo, si está escribiendo código reutilizable, debe refactorizarlo para que no contenga manipulación de UI y manejar la excepción en un nivel superior en la pila de llamadas.

Answer 6

Dado que está protegiendo la excepción (y no volviéndolo a lanzar) en su ejemplo, el código externo asume que todo está bien y por lo tanto debe devolver algo útil.

Si necesita detectar la excepción y hacer algo bien, pero si todavía es un error, también debería lanzarlo, o una excepción diferente, tal vez con la que acaba de capturar como InnerException.

Answer 7

Me asumir todavía se puede configurar el mensaje, y luego volver nulo o cualquiera que sea el equivalente C# es

public DataTable ReturnSomething(){ 
    try { 
     //logic here 
     return ds.Tables[0]; 
    } catch (Exception e) { 
     ErrorString=e.Message; 
     return null; 
    } 
} 

Answer 8

¿Qué tal esto:

public DataTable ReturnSomething(out string errorString) 
{ 
    errorString = string.Empty; 
    DataTable dt = new DataTable(); 
    try 
    { 
     //logic here 
    dt = ds.Tables[0]; 
    } 
    catch (Exception e) 
    { 
     errorString = e.Message; 
    } 
    return dt; 
} 

Answer 9

Si va a la cabeza del " no ejecute una ruta de excepción "(que no estoy recomendando necesariamente), podría seguir el enfoque TryParse que utiliza MS.

Algo así como:

private string FillDataTable(out DataTable results) 
{ 

    try 
{ 
    results = new DataTable(); //something like this; 
    return String.Empty; 
} 
catch (Exception ex) 
{ 
    results = null; 
return ex.Message; 

} 

}

Answer 10

La variable ErrorString se parece sospechosamente a una variable de código de error. La práctica recomendada es usar excepciones para pasar información de error directamente, cuando sea necesario, en lugar de almacenar cosas en códigos de error.

Está haciendo efectivamente lo mismo con su ErrorString como lo haría si solo deja que la persona que llama capte la excepción: eliminando la responsabilidad de responder a un error del método en sí. Este es un buen objetivo para tener. Pero el uso de una cadena de error no le gana nada sobre el uso de una excepción. De hecho, pierdes información de esta manera. Existe una cantidad de tipos de errores que pueden ocurrir y muchos tienen excepciones especiales asociadas a ellos, con sus propias propiedades especiales para contener información contextual sobre el error. Al guardar el mensaje en una cadena, está perdiendo esta información.

De modo que, a menos que su objetivo sea específicamente ocultar el tipo de error que está ocurriendo en la persona que llama, solo puede ganar dejando pasar la excepción.

Otra cosa a considerar es si este es realmente un escenario de error. Si es así, es muy poco probable que a su método de llamada le importe en absoluto cuál es el valor de retorno. En ese caso, no tiene nada de qué preocuparse simplemente dejando que la excepción se ejecute y no devuelva nada. Si NO es realmente un escenario de error, y la persona que llama solo va a continuar y hacer otra cosa, bueno, eso es para que la persona que llama lo decida, ¿no? Todavía no hay mucho beneficio que obtener al devolver una cadena de error y una DataTable ficticia o un nulo, antes de arrojar la excepción con toda su información de falla contextual.

Answer 11

Lo puede hacer como el código de ejemplo siguiente.

public DataTable ReturnSomething(out string OutputDesc) 
{ 
    try 
     { 
     //logic here 
     OutputDesc = string.Format("Your Successful Message Here..."); 
     return ds.Tables[0]; 
     } 
     catch (Exception e) 
     { 
     OutputDesc =e.Message; 
     return null; 
     } 

}