c# - ¿Puedo eliminar la captura vacía con el tiro?

.net exception-handling

Question

Espero que esto sea sencillo. Trabajo en una base de código grande, la calidad general es buena, pero ocasionalmente obtienes algo de esto:

try
{
// Calls a .NET remoting method.
}
catch
{
throw;
}

Tenga en cuenta que no hay una lógica definitiva y que la captura no especifica ninguna excepción ni hace nada que no sea lo que he proporcionado anteriormente. Sin embargo, sé que capturar y volver a lanzar puede alterar la pila de llamadas en los detalles de la excepción. De lo que no estoy seguro es si este comportamiento está aquí específicamente debido a una llamada remota de .NET.

¿Es seguro eliminar este try-catch? Por lo que puedo ver, lo es, pero pensé que primero verificaría cualquier comportamiento extraño.

Answer 1

En ciertas situaciones relacionadas con la seguridad de acceso al código, la cláusula catch-rethrow puede ser una característica de seguridad necesaria. Pero dudo que se aplique aquí. Especialmente porque ninguna persona sensata usaría este patrón sin agregar un comentario.

El objetivo de esto es evitar que se ejecuten los filtros de excepción mientras se tienen mayores privilegios.

Algunos artículos relacionados:

http://blogs.msdn.com/b/shawnfa/archive/2005/03/31/404320.aspx
http://msdn.microsoft.com/en-us/library/8cd7yaws(v=VS.100).aspx
http://www.pluralsight-training.net/community/blogs/keith/archive/2005/03/31/7149.aspx

Parece estar obsoleto desde .net 2:
Suplantación y filtros de excepción en v2.0

Answer 2

Por lo que sé, catch (Exception ex) { throw ex } restablece el seguimiento de la pila. Y acaba de catch { throw; } catch { throw; } no lo hace.

Entonces, si no realiza ninguna lógica adicional en caso de error, por ejemplo, el registro, no conozco ninguna razón para no eliminar esa captura.

Answer 3

Si bien, en la mayoría de los casos, es probable que sea un código redundante / innecesario, try { .. } catch { throw; } try { .. } catch { throw; } puede suprimir las optimizaciones del compilador y el método JIT en línea. Esto se ve principalmente en las trazas de pila de llamadas.

Por lo tanto, "podría" haber un efecto secundario que se confía en otra parte.

Podría decirse que el ''error'' dependería de este detalle de la implementación, especialmente sin documentación explícita sobre dicho comportamiento esperado ... y especialmente porque no es una garantía.

Vea la publicación NO ES depuración: Optimizaciones de 64 bits y el método C # en las pilas de llamadas de compilación de la versión que anteceden incluso a esta pregunta anterior.

Si bien el código parece redundante, el código try-catch tampoco se eliminará durante la compilación .

Answer 4

Si vuelve a mostrarlo, no debería cambiar la pila de llamadas, a menos que haya algo muy especial en las excepciones remotas. (Sé que hay algunos aspectos especiales, pero no creo que entren en juego aquí). Este es el tipo de cosa que pierde información:

catch(Exception e)
{
throw e; // Not throw;
}

Supongo que algunos desarrolladores han incluido esto solo para que puedan poner un punto de interrupción en la línea de throw . Me libraría de ello.