¿Por qué las excepciones no están registradas en .NET?

Sé que Google puede encontrar una respuesta adecuada, pero prefiero escuchar sus opiniones personales (y quizás técnicas).
¿Cuál es la razón principal de la diferencia entre Java y C # al lanzar excepciones?
En Java, la firma de un método que arroja una excepción tiene que usar la palabra clave “throws”, mientras que en C # no se sabe en tiempo de comstackción si se puede lanzar una excepción.

Porque la respuesta a las excepciones marcadas casi siempre es:

try { // exception throwing code } catch(Exception e) { // either log.error("Error fooing bar",e); // OR throw new RuntimeException(e); } 

Si realmente sabe que hay algo que puede hacer si se lanza una excepción en particular, puede atraparla y luego manejarla, pero de lo contrario solo son encantamientos para apaciguar al comstackdor.

En el artículo The Trouble with Checked Exceptions y en la propia voz de Anders Hejlsberg (diseñadora del lenguaje C #), hay tres razones principales para que C # no admita excepciones comprobadas, ya que se encuentran y se verifican en Java:

  • Neutral en las excepciones marcadas

    “C # es básicamente silencioso en el problema de excepciones comprobadas. Una vez que se conoce una solución mejor, y créanme, seguimos pensando en ello, podemos retroceder y realmente poner algo en su lugar “.

  • Versiones con excepciones controladas

    “Agregar una nueva excepción a una cláusula throws en una nueva versión rompe el código del cliente. Es como agregar un método a una interfaz. Después de publicar una interfaz, es para todos los propósitos prácticos inmutable, … ”

    “Es curioso cómo la gente piensa que lo importante de las excepciones es manejarlas. Eso no es lo importante acerca de las excepciones. En una aplicación bien escrita, hay una relación de diez a uno, en mi opinión, de intentar finalmente probar la captura. O en C #, using declaraciones, que son como intentar finalmente “.

  • Escalabilidad de las excepciones controladas

    “En las pequeñas, las excepciones comprobadas son muy atractivas … El problema comienza cuando comienzas a construir grandes sistemas en los que hablas con cuatro o cinco subsistemas diferentes. Cada subsistema arroja de cuatro a diez excepciones. Ahora, cada vez que subes por la escalera de la agregación, tienes esta jerarquía exponencial debajo de ti de las excepciones con las que tienes que lidiar. Terminas teniendo que declarar 40 excepciones que podrías lanzar … Simplemente se sale de control “.

En su artículo, ” ¿Por qué C no tiene especificaciones de excepción? “, Anson Horton (Administrador de progtwigs de Visual C #) también enumera los siguientes motivos (consulte el artículo para obtener detalles sobre cada punto):

  • Versiones
  • Productividad y calidad de código
  • Impracticality de tener el autor de la clase diferenciar entre las excepciones marcadas y no marcadas
  • Dificultad para determinar las excepciones correctas para las interfaces.

Es interesante observar que C #, sin embargo, admite la documentación de excepciones lanzadas por un método determinado a través de la etiqueta y el comstackdor incluso se toma la molestia de verificar que el tipo de excepción al que se hace referencia existe. Sin embargo, no se realiza ningún control en los sitios de llamadas ni en el uso del método.

También puede consultar el Exception Hunter , que es una herramienta comercial de Red Gate Software , que utiliza el análisis estático para determinar e informar excepciones generadas por un método y que pueden no ser detectadas:

Exception Hunter es una nueva herramienta de análisis que encuentra e informa el conjunto de posibles excepciones que pueden arrojar tus funciones, incluso antes de enviar. Con él, puede localizar excepciones no controladas de forma fácil y rápida, hasta la línea de código que arroja las excepciones. Una vez que tenga los resultados, puede decidir qué excepciones se deben manejar (con algún código de manejo de excepciones) antes de lanzar su aplicación en libertad.

Finalmente, Bruce Eckel , autor de Thinking in Java , tiene un artículo titulado, ” ¿Necesita Java excepciones controladas? “, Que puede valer la pena leer también porque la pregunta de por qué las excepciones comprobadas no están en C # suele enraizarse en las comparaciones con Java.

La filosofía básica del diseño de C # es que realmente la captura de excepciones rara vez es útil, mientras que la limpieza de recursos en situaciones excepcionales es bastante importante. Creo que es justo decir que using (el patrón IDisposable) es su respuesta a las excepciones marcadas. Ver [1] para más.

  1. http://www.artima.com/intv/handcuffs.html