¿Por qué C # no tiene soporte para el filtrado de excepciones de primer paso?

Question

Nota: esto no es un duplicado de la pregunta de Jeff .

Esa pregunta "& es; ¿Es un equivalente? " Sé que no hay, y quiero saber por qué!

La razón por la que pregunto es que acabo de aclarar lo importante que es, y la conclusión me parece muy extraña.

El bloque de manejo de excepciones de Enterprise Library de Microsoft nos aconseja usar este patrón:

catch (Exception x)
{
    if (ExceptionPolicy.HandleException(x, ExceptionPolicies.MyPolicy))
        throw;

    // recover from x somehow
}

La política se define en un archivo XML, por lo que eso significa que si un cliente tiene un problema, podemos modificar la política para ayudar a rastrear (o quizás eliminar) el problema para darles una solución rápida hasta que resolvamos con él adecuadamente, lo que puede implicar discutir con terceros, acerca de quién tiene la culpa.

Esto es básicamente un reconocimiento del simple hecho de que en las aplicaciones reales el número de tipos de excepción y su capacidad de recuperación " El estado es prácticamente imposible de administrar sin una instalación como esta.

Mientras tanto, el equipo de CLR en MS dice que esto no es una opción, ¡y resulta que esos chicos saben de lo que están hablando! El problema es que justo antes de que se ejecute el bloque catch , se ejecutará cualquier bloque finalmente anidado dentro del bloque try . Por lo tanto, esos bloques finalmente pueden hacer lo siguiente:

• Modifique el estado del programa de forma inofensiva (phew, lucky).
• Deshágase de algo importante en los datos del cliente, porque el estado del programa se confunde hasta un grado desconocido.
• Disimule o destruya evidencia importante de que necesitamos diagnosticar un problema, especialmente si estamos hablando de llamadas al código nativo.
• Lanzar otra excepción, lo que aumenta la confusión y la miseria en general.

Tenga en cuenta que la declaración utilizando y los destructores C ++ / CLI se basan en try / finalmente , por lo que también se ven afectados.

Claramente, el patrón catch / throw para filtrar excepciones no es bueno. Lo que realmente se necesita es una forma de filtrar las excepciones, a través de una política, sin capturarlas realmente y, por lo tanto, desencadenar la ejecución de los bloques finally , a menos que encontremos una política que nos indique que es seguro recuperar la excepción. .

El equipo de CLR hizo un blog sobre esto recientemente:

• Catch, Rethrow and Filters - ¿Por qué debería importarte?
• Por qué la captura (Excepción) / captura vacía es mala

El resultado es que tenemos que escribir una función auxiliar en VB.NET para permitirnos acceder a esta capacidad vital desde C #. La gran pista de que hay un problema es que hay un código en el BCL que hace esto. Mucha gente ha escrito en su blog acerca de hacerlo, pero rara vez mencionan el tema de los bloques try / finalmente , que es el asesino.

Lo que me gustaría saber es:

• ¿Hay declaraciones públicas o correos electrónicos directos que las personas hayan recibido del equipo de C # sobre este tema?
• ¿Hay alguna sugerencia existente de Microsoft Connect que solicite esto? He escuchado rumores de ellos, pero ninguna de las palabras clave probables apareció.

Actualización: como se indicó anteriormente, ya he buscado en Microsoft Connect sin encontrar nada. También he (como era de esperar) en Google. Solo encontré personas explicando por qué necesitan esta función , o señalando Las ventajas de la misma en VB.NET , o infructuosamente esperando que sea agregado en una versión futura de C # , o trabajando a su alrededor , y un montón de consejo engañoso . Pero no hay ninguna declaración sobre el fundamento para omitirlo de todas las versiones actuales de C #. Y la razón por la que pregunto sobre los problemas existentes de Connect es que (a) no creo un duplicado innecesario y (b) puedo informar a las personas interesadas si tengo que crear uno.

Actualización 2: encontrado una interesante publicación de blog de Eric Gunnerson , anteriormente del equipo de C #:

  

" Sí, poder poner una condición en   una captura es algo más conveniente   que tener que escribir la prueba   a ti mismo, pero realmente no permite   que hagas algo nuevo. "

¡Ese era el mismo supuesto que tenía hasta que me lo explicaron correctamente!

Answer 1

En cuanto a cualquier error de conexión existente. El siguiente problema trata con los fliters de excepción. El usuario no declaró explícitamente que deseaba que fuera un filtro real en el sentido de cuándo se ejecutan, pero en mi humilde opinión está implícito en la lógica.

https://connect.microsoft.com/VisualStudio/feedback /ViewFeedback.aspx?FeedbackID=401668

Además de ese problema, no hay problemas que pueda encontrar o saber que estén relacionados con lo que está buscando. Creo que sería bueno tener un problema separado que exprese explícitamente la necesidad de filtros de excepción de estilo VB.Net.

No me preocuparía demasiado introducir una pregunta duplicada si ha hecho un poco de diligencia debida en busca de una existente. Si hay un duplicado, Mads lo engañará en consecuencia y lo vinculará a la solicitud principal.

En cuanto a la parte de obtener una respuesta oficial del equipo de C #, es probable que lo consiga cuando 1) presente un error de conexión o 2) se engañe contra el error principal. Realmente dudo que exista una razón / justificación oficial ahora mismo.

Aquí está mi especulación sobre el tema: supongo que esta característica simplemente no estaba en el conjunto de características C # 1.0 original y desde ese momento no ha habido suficiente demanda para ingresar a la idioma. El equipo de C # y VB pasa una increíble cantidad de tiempo clasificando las características del idioma al comienzo de cada ciclo de envío. Tenemos que hacer algunos cortes muy muy difíciles a veces. Sin la demanda suficiente, hay muy pocas posibilidades de que una característica llegue al idioma.

Hasta hace poco, apuesto a que sería muy difícil encontrar a 1 de cada 10 personas que entendieron la diferencia entre la opción Int / When de VB.Net y solo usar una instrucción if simple en un bloque catch de C #. Últimamente parece estar un poco más en la mente de la gente, así que quizás se convierta en una versión futura del lenguaje.

Answer 2

El uso de Inyección de filtro de excepción puede ser más sencillo que usar la solución alternativa de delegado.

Para obtener una respuesta real a su pregunta, necesitará una respuesta de Anders Hejlsberg o de alguien que haya estado en las reuniones de diseño originales. Puede intentar ver si el entrevistador del Canal 9 lo puede pedir la próxima vez se entrevista al equipo de diseño de C # .

Supongo que cuando se tomó la decisión original, los filtros de excepción se vieron como una complicación innecesaria que podría hacer más daño que bien. Ciertamente, puede ver el deseo de permanecer 'silencioso' sobre las características no probadas en esta entrevista sobre la decisión de no admitir excepciones comprobadas: El problema con las excepciones comprobadas .

Creo que los escenarios de diagnóstico postmoterm argumentan fuertemente para proporcionar acceso a filtros de excepción en el idioma. Sin embargo, esos escenarios pueden no haber sido articulados en el momento. Además, esos escenarios realmente necesitan un soporte adecuado de herramientas, que ciertamente no estaba disponible en V1. Finalmente, puede que haya grandes aspectos negativos sobre la adición de esta función que no estamos considerando.

Si no hay un error de conexión en esto, debes ingresar uno y animar a otros a votar. [Recomendaría solicitar el acceso a la función CLR en lugar de intentar diseñar cómo encaja en el idioma.]

Answer 3

Tampoco creo que Java tenga una opción de filtro. Suponiendo que si lo hiciera, también veríamos uno en C #. VB.net probablemente tiene uno por casualidad dado que el equipo de VB comenzó con una pizarra limpia.

Una cosa que podría funcionar a su favor en la medida en que obtenga esta opción en una versión futura de C # es el objetivo declarado de Microsoft de mantener la paridad entre las funciones de lenguaje en las versiones futuras de C # y VB.net. Me gustaría presentar mi argumento basado en eso.

http://www.chriseargle.com/post /2009/01/Parity-Between-Languages.aspx

Answer 4

En lo que respecta a la primera pregunta, si hubo una declaración pública, entonces es más que probable que se coloque en la web en algún lugar, en cuyo caso, Google debería mostrar algo (si existe).

Si es un correo electrónico directo con el equipo de C #, es muy probable que esté bajo NDA, por lo que no podría publicarse de todos modos.

Con la segunda pregunta, hay una función de búsqueda en Microsoft Connect que le piden que use antes de ingresar una nueva sugerencia. Si no puede encontrarlo, entonces probablemente no haya uno.

Mi recomendación sería poner una sugerencia, y luego promoverla para que otros la apoyen.

Answer 5

Como los entiendo, en el momento del rebrote, los manejadores finalmente en las funciones internas se ejecutan y eso es lo que crea problemas para usted.

Pero digamos que tiene un filtro de excepción que pasa la excepción sin volver a generarla. Aún tendrás que manejarlo de alguna manera en algún lugar, y correrás en los mismos tipos de problemas (finalmente efectos) allí.

Por lo tanto, a menos que esté mal entendiendo algo, no hay una gran ventaja de tener filtros de excepción compatibles con el idioma.

Answer 6

Puedo pensar en al menos dos razones por las que el filtro de excepciones está ausente en C #

1. Permitir filtros de excepción podría alentar a los programadores a hacer cosas durante el manejo de excepciones de primer paso, lo que sería inseguro en ese momento, aunque podrían hacerse de manera segura dentro de una "captura" o "finalmente". Por ejemplo, si el código dentro del " intente " el bloque adquiere un bloqueo y lanza una excepción mientras se mantiene el bloqueo, el bloqueo se mantendrá durante la ejecución de los filtros de excepción externos, pero se liberará antes de un " captura " externo o " finalmente " Se ejecuta el bloque. Además, al menos la última vez que lo verifiqué, las excepciones que ocurrieron dentro de un filtro de excepción y que no quedaron atrapadas dentro de él se silenciaron silenciosamente, algo así como una situación fea.
2. Los implementadores de C # tienen la visión de hacer que su lenguaje sea 'marco agnóstico'. Si C # admitió el filtrado de excepciones de primer paso de .net, los programas que usaron esa función podrían ser inutilizables en marcos que manejan las excepciones de manera diferente. Esta es la misma razón por la que C # prohíbe a los programas anular `Object.Finalize ()`. Si bien el razonamiento que rodea a `Object.Finalize ()` es defectuoso (el uso correcto de los destructores requiere el uso de otros métodos específicos de la plataforma, por lo que no requiere el uso de la sintaxis del destructor para que `Object.Finalize ()` no logre nada, excepto que el t77o fomente la escritura de software defectuoso) el razonamiento tiene algún sentido con respecto a los filtros de excepción. Por otro lado, la forma correcta de lidiar con ese problema sería exponer algunas características relacionadas con el filtro de excepción, incluso si una no expusiera directamente los filtros de excepción.

Una característica que realmente me gustaría ver en C # y vb, que requeriría el uso de filtros de excepción para implementar pero que no requeriría exponerlos directamente, sería un parámetro opcional de Exception para un bloque finalmente . Este parámetro sería null si no se produce una excepción no detectada; De lo contrario tendría la excepción en cuestión. Esto permitiría situaciones en las que un programa querrá hacer algo cuando se produce una excepción, pero en realidad no " manejar " eso. En la mayoría de los casos, el parámetro Exception no se usaría para nada excepto para verificar null (lo que significa que la función sería equivalente a exponer el error ) bloques), pero ofrecería ventajas en los casos en que se produzca una excepción durante la limpieza. Actualmente, si se produce una excepción durante un bloque finally , es necesario ya sea para sofocar la excepción finally o sobrescribir la anterior. Tener la excepción anterior disponible para el código de bloque finally permitiría ajustarlo o registrarlo.