Soy un desarrollador de C# que hace codificación ocasional en Java. ¿Alguien puede explicar en términos simples qué excepciones están marcadas en Java y por qué es necesario? No he encontrado este término en C#.¿Qué son excepciones marcadas en Java/C#?
Las excepciones comprobadas son excepciones que el compilador requiere que maneje de alguna manera.
En Java, las excepciones marcadas son Throwable s que no son RuntimeException, Error, o una de sus subclases.
Los diseñadores de Java consideraron que eran necesarios para garantizar que los programas manejaran excepciones que eran razonablemente probables. Un ejemplo clásico es IOException. Cada vez que un programa realiza E/S, existe la posibilidad de falla. El disco puede estar lleno, el archivo puede no existir, puede haber un problema de permisos, etc.
Por lo tanto, Java está diseñado de forma que un programa debe manejar sintácticamente la excepción de alguna manera. Esto podría ser con un bloque catch, o volviendo a lanzar la excepción de alguna manera.
C# no tiene excepciones marcadas. Decidieron dejar este problema a los desarrolladores de la aplicación (interview). Las excepciones controladas son controvertidas porque pueden hacer que el código sea prolijo, mientras que los desarrolladores a veces las manejan trivialmente con bloques de captura vacíos. Además, puede ser arbitrario qué métodos de biblioteca estándar arrojan excepciones marcadas. Por ejemplo, ¿por qué File.delete (una nueva API de Java 7 no lo hace de manera diferente) lanza IOException?
Otra preocupación que Hejlsberg notó en esa entrevista es la viabilidad. Agregar una excepción marcada a una cláusula throw obliga a todos los códigos que utilizan ese método a ser modificados y recompilados.
explicación increíble. ¡Gracias! – blitzkriegz
'Agregar una excepción marcada a una cláusula throw obliga a todos los códigos que utilizan ese método a ser modificados y recompilados', por lo que tiene excepciones sin marcar. Bueno, excepto si crees que 'Fallará en algunas circunstancias' es cómo te gustaría describir tu API. CADA excepción es parte de la interfaz pública de un método, agregar las posteriores es como decir "Ah, y de ahora en adelante ese parámetro int tendrá un significado semántico completamente diferente, pero no se preocupe, ¡sigue siendo compatible con binarios!" – Voo
@Voo, esto se trata específicamente en [esta parte] (http://www.artima.com/intv/handcuffs2.html) de la entrevista. Hejlsberg argumenta que no todas las excepciones realmente deben ser manejadas por el código de llamada inmediata. Él dice que algunos son manejados mejor por el manejador principal de mensajes, incluso si ese manejador principal no fue escrito con conocimiento específico de la nueva excepción. –
Las excepciones comprobadas son excepciones que requieren que cualquier clase "consumidora" tenga que codificar que verifica explícitamente (y con suerte maneja) la excepción.
Por ejemplo, si la clase Apple tiene un método Eat() que incluye la excepción comprobada de WormFound, cualquier código que invoque ese método deberá tener explícitamente un inconveniente para esa excepción.
Como nota al margen, es característica de Java y no de C#.
(En el punto en que se creó C#, los pros de excepciones comprobadas no eran tan evidentes a los ojos del equipo de C# para que no se incluyeron.)
En Java, un excepción comprobado (como señala correctamente Matthew Flaschen) es una excepción que el compilador requiere que manejes. Estas son las excepciones que se declaran en las definiciones de función (por ejemplo function bob() throws ImNotBobException { ... } decir que llamar a esa función puede lanzar esa excepción -. Ej NumberFormatException al analizar un número entero, o IOException al escribir en un archivo
Sin embargo, algunas excepciones pueden ser lanzadas desde lugares desconocidos o inesperados que simplemente no son prácticos de manejar en todos los niveles, por lo que el compilador no requiere que los maneje. Estos son excepciones sin marcar. Se pueden lanzar desde varios lugares que no declaran arrojarlos (a menudo intentando llamar a un método en un objeto cuando ese objeto aún no se ha inicializado, es decir, es nulo; esto dará como resultado un NullPointerException.)
Espero que esto ayude.
excepción comprobada es un error. Cualquier otra explicación es incorrecta. – earizon
(unos años más tarde, para las personas que llegan aquí a través de Google aerolíneas)
sometido a control de excepciones fue un error en el diseño del lenguaje Java. PERÍODO. Siempre que encuentre una excepción marcada, envuélvalos en una excepción sin marcar (probablemente una RuntimeException).
Desafortunadamente, debido a problemas de comercialización, primero Sun, Oracle no pudo reconocer abiertamente su error.
En el momento en que se creó Java, el manejo de excepciones no estaba claro. Los diseñadores de Java ingenuamente pensaron que forzar a los desarrolladores a verificar excepciones en tiempo de compilación era una buena idea. Si bien esto parece intuitivamente correcto, esto se convirtió en un antipatrón, similar al uso de "GOTO". Nunca funcionó en la práctica y causa muchos problemas. Las excepciones se deben manejar en un "bucle principal" o "controlador", ya que de lo contrario, si se pudieran manejar dentro de la función que genera el error, no serían una excepción, sino un error contemplado que debe ser respaldado por el valor de retorno API normal. Una excepción, por su propia naturaleza, es algo que no se contempla y que no permite la ejecución de flujo normal del código.
Observe, por ejemplo, que Spring, el marco de trabajo "estándar" de Java para el desarrollo de aplicaciones empresariales, solo limita el ajuste de las excepciones comprobadas en excepciones sin marcar.
C# corrigió este problema. De hecho, C# no tiene este problema.
¿Querías decir "excepciones marcadas"? Por favor, edite la pregunta si lo hizo. – dasblinkenlight
@dasblinkenlight, se etiquetó como excepción, así que lo edité. –
gracias! perdón por ese error tipográfico. – blitzkriegz