Si se comprueba nulo

Question

Sé que siempre debe verificar params entrantes a un método para null. Pero, ¿qué sucede si tengo este escenario con un try/catch que hace referencia a una variable local? ¿Realmente necesito verificar null a continuación? Debido a que va a la captura de todos modos si es nula y la siguiente línea de código intenta utilizar la variable refundResponse:

public string DoRefund(...) 
    { 
     try 
     { 
    ...... 
      string refundTransactionID = string.Empty; 
    ...... 

      RefundTransactionResponseType refundResponse = transaction.DoRefund(...); 

      if (refundResponse != null) 
       refundTransactionID = refundResponse.RefundTransactionID; 
    ..... 
     } 
     catch (Exception ex) 
     { 
      LogError(ex); 
      return ex.ToString(); 
     } 
    } 

Recuerda que estoy hablando específicamente de las variables locales y la comprobación de los dentro de un método, no params entrantes a una método.

Todo lo que estoy preguntando es si necesito comprobar null antes de configurar refundTransactionID o simplemente lo configuro sin el si suponiendo que el compilador manejará y arrojará si es nulo que será capturado y devuelto como una cadena para la persona que llama en este caso.

o debe ser

if (refundResponse == null) 
       return null; 

o simplemente tomar el cheque completo para esta asignación variable local y, a continuación, ya que en este caso tengo un try/catch estoy manejando cualquier excepción recogido por el compilador de forma natural mediante la devolución de la excepción como una cadena a la persona que llama (no fue mi decisión de enviar de regreso una cadena, que era un requisito de mi jefe ... por lo que el debate de derivación por ahora):

refundTransactionID = refundResponse.RefundTransactionID; 

en última instancia, la el resto del código más abajo en el método depende de n un reembolso válidoTransactionID.

Answer 1

Las excepciones son por condiciones excepcionales. Si puede verificar si hay un error continuo, ¡hágalo, por favor!

Answer 2

No, no es necesario que compruebe nulo, allí. Sin embargo, eso abre otra pregunta, ¿realmente necesita verificar los parámetros entrantes?

Recuerda: eso es un comportamiento. Tienes que probar ese comportamiento.

Answer 3

Sugiero comprobar el nulo y luego hacer algún tipo de manejo de error suave en lugar de simplemente dejarlo atrapar y lanzar un mensaje de error.

Answer 4

Pero si no puede continuar en ese punto, deje que la excepción se propague.

Answer 5

Sé que siempre debe verificar parámetros entrantes a un método para null.

No, no necesariamente. Lo que debe especificar es el contrato de su método. Es perfectamente aceptable (y común) especificar que arrojará una NullPointer/NullReferenceException para un parámetro null. Entonces no necesitas ninguna verificación.

También puede verificar la nulidad, pero esto solo tiene sentido si realmente puede manejar un nulo de manera útil (por ejemplo, sustituir un valor predeterminado).

Answer 6

Debería tener que comprobar nulo en esa instancia. La lógica de su aplicación debe ser capaz de manejar este tipo de situaciones, sin la necesidad de excepciones.

Answer 7

No, no parece que deba verificar nulo aquí. Y tampoco verificaría nulo para TODOS los parámetros entrantes (como sugiere su descripción).

También es extraño que esté devolviendo un transactionID como una cadena O el mensaje de una excepción. ¿Cómo sabrá la persona que llama de este método si ocurrió una excepción?

Si realmente desea registrar la excepción, ¿qué tal algo como esto:

public string DoRefund(...) 
    { 
     try 
     { 
      return transaction.DoRefund(...).RefundTransactionID; 
     } 
     catch (Exception ex) 
     { 
      LogError(ex); 
      throw ex; 
     } 
    } 

Answer 8

Una alternativa a las pruebas es la Null Object pattern. En lugar de devolver Null, o una transacción válida, el método transaction :: DoRefund() devuelve un objeto nulo: un objeto que ofrece la misma interfaz que las instancias RefundTransactionResponseType, pero sus métodos no hacen nada. Con esto no hay necesidad de probar si para Null.

El debe ser utilizado con prudencia ya que esto puede ocultar fácilmente los problemas.

Answer 9

Debe verificar el nulo en lugar de dejar que el manejo de excepciones lo maneje. Como dijo Leppie, las excepciones son para condiciones excepcionales y no para un flujo de control normal. Si sabes qué problemas pueden ocurrir, entonces debes manejarlos con elegancia.

Otra cosa a tener en cuenta es el impacto en el rendimiento de las excepciones. Cuando se lanza la excepción, la JVM tiene que desenrollar la pila de llamadas. En su ejemplo, la excepción también se registra. Todo esto lleva tiempo y es mucho más lento que un simple control "si".

Answer 10

Depende de lo que signifique para su programa cuándo (refundResponse == null). Si esto tiene algún significado, entonces tiene sentido informar un error más informativo. Si nunca debería ocurrir e indicaría un error en el método DoRefund, entonces creo que está bien permitir que el nulo cause una excepción más adelante. En el último caso, solo tendría un control específico si sospecha del método y si se está comportando como debería.