2008-12-03 15 views
9

En un servicio web que ver este código:¿Por qué atrapar una excepción solo para tirarla de nuevo?

<WebMethod()> _ 
Public Function dosomething() As Boolean 
    Try 
     If successful Then 
      Return True 
     Else 
      Return False 
     End If 
    Catch ex As Exception 
     Throw ex 
    End Try 
End Function 

Cuál es el punto de agarrar la excepción y sólo tirar de nuevo? ¿Extraño algo?

Edit: Gracias por las respuestas! Pensé que era algo así, pero no estaba seguro si podría/podría refactorizarlos sin ninguna implicación.

Respuesta

11

No puedo pensar en ninguna razón para hacer esto por la funcionalidad. Sin embargo, puede surgir cuando anteriormente se eliminó algún tipo de manejo de errores (normalmente el registro), y el desarrollador eliminó el manejo del registro pero no reestructuró el código para eliminar el try/catch redundante.

5

Probablemente queda un poco de código de depuración (establecería un punto de interrupción en el lanzamiento para que pueda examinar la excepción en el depurador). Podría hacer algo como esto si quisiera registrar la excepción y luego pasarla por la cadena, aunque probablemente incluiría la excepción en otra con un mensaje de error más significativo (para mi aplicación).

40

No haga esto.

Si necesita volver a generar la excepción, simplemente use throw; usando throw ex; borra el rastreo de la pila y es absolutamente incorrecto.

+0

Cuál es otra razón por la que me envuelve como una excepción interna si necesitaba hacer esto para el registro. – tvanfosson

+0

¿Por qué? Solo tira la excepción original. El registro no debe cambiar o alterar nada. – GEOCHET

+3

Para agregar mi propia semántica a la excepción. Ex.Obtengo una SqlException porque intento insertar una fila con una clave primaria duplicada. En mi método, sé qué tipo de objeto y qué valor clave se está insertando. Puedo escribir un mensaje de excepción mejor y aun así conservar toda la información. – tvanfosson

-8

Es posible que desee hacerlo si desea detectar una excepción, excepto una subclase de la misma.

Por ejemplo,

try { 
    // Something stupid 
} 
catch(RuntimeException e) { 
    throw e; //Handle it outside 
} 
catch (Exception e) { 
    // I'm dead 
} 
+2

Pero todavía no desea llamar "arrojar e". Usted quiere "arrojar" en su lugar. Llamar a "arrojar e" deja caer la información de la pila hasta ese punto, y es peligroso. –

+2

INCORRECTO INCORRECTO INCORRECTO. POR FAVOR NO LE DIGA A LA GENTE ESTO. – GEOCHET

+0

The throw e; obviamente está mal, pero aparte de eso, esta es una idea interesante. Sin embargo, no estoy seguro de si hay un caso de uso ... – Quibblesome

3

Una de las arquitecturas (design patterns) pude ver esta siendo utilizado en está donde está siendo manejado una transacción. La función hace su trabajo, falla y el bloque catch completa la transacción a un estado conocido (por lo general, un rollback) y luego arroja una excepción definida por el usuario.

Como está parado ahora, refactorice ese código a un estado más sano.

1

El try/catch no solo es inútil, sino que también lo es el IF. Toda la función se puede reducir a una línea:

return successful 

En ese momento, ¿para qué molestarse? ¿Por qué no simplemente probar "con éxito" en lugar de llamar a la función?

Bueno, está bien, es un método web, supongo que necesitas la función solo para darle a Ajax o quien sea un controlador.

(Sí, soy consciente de que mi respuesta es de 7 años de retraso. Yo sólo me encontré con este en la búsqueda de algo sin relación.)

-2

El patrón para el monitor hace que este muy probable que volver a lanzar un error como sea necesario un Monitor.Exit fin de asegurar se llama

https://msdn.microsoft.com/en-us/library/4tssbxcw(v=vs.110).aspx

Dim lockObj As New Object() 

If Monitor.TryEnter(lockObj) Then 
    Try 
     ' The critical section. 
    Catch 
     throw 
    Finally 
     ' Ensure that the lock is released. 
     Monitor.Exit(lockObj) 
    End Try 
End If 
Cuestiones relacionadas