Curioso: ¿Por qué es necesaria la sintaxis "throws <SomeSpecific> Exception" solo en Java?

Question

Todos sabemos que es necesario.

Pero ¿POR QUÉ es necesario solo en Java, cuando otros lenguajes similares que tienen capacidades de manejo de excepciones no requieren que escribamos "throws Exception"? ¿Hay alguien que sepa lo que estaba sucediendo cuando se diseñó el lenguaje Java y por qué lo hicieron de esa manera? Sólo curioso.

P.S. Puede que esta no sea una pregunta práctica o realmente necesaria; puede que no me ayude de todos modos con mis proyectos en curso. Pero ciertas características del lenguaje encienden mi curiosidad: D

Editar ¡Parece que mi pregunta era muy vaga! Creo que formulé la pregunta erróneamente. Necesitamos utilizar el tipo de sintaxis "throws Exception" en algunos puntos durante la programación cuando se trata de código Java. Pero algo así nunca se necesita en C# o C++ o incluso en VB.Net y PHP. Entonces, ¿por qué Java solo insiste en esto?

Answer 1

Como otras respuestas aquí han señalado, la cláusula throws sólo se requiere para checked exceptions, que es una característica que actualmente sólo existe en Java.

La respuesta oficial de por excepciones por qué Java ha facturado se well documented:

¿Por qué los diseñadores deciden forzar un método para especificar todos los uncaught excepciones que pueden ser lanzadas dentro de su ámbito comprobado ? Cualquier Excepción que puede ser lanzada por un método es parte de la interfaz de programación pública del método . Aquellos que llaman a un método deben conocer las excepciones que un método puede arrojar para que puedan decidir qué hacer con ellos. Estas excepciones son una parte tan importante de la interfaz de programación del método como sus parámetros y su valor de retorno.

Sin embargo, esta decisión es highly controversial, incluso dentro de la comunidad de Java:

Recientemente, varios bien considerado expertos, entre ellos Bruce Eckel y Rod Johnson, han declarado públicamente que mientras que inicialmente acuerdo completamente con la posición ortodoxa en excepciones comprobadas, han concluido que uso exclusivo de excepciones comprobadas es idea no tan buena como apareció en primero, y las excepciones comprobadas se han convertido en una fuente importante de problemas para muchos proyectos grandes. Eckel toma una vista más extrema, sugiriendo que todas las excepciones deben ser desmarcadas; La opinión de Johnson es más conservadora, pero aún sugiere que la preferencia ortodoxa para las excepciones marcadas es excesiva. (Vale la pena señalando que los arquitectos de C#, que casi seguro que tenía un montón de experiencia en el uso de la tecnología Java, elegir omitir excepciones comprobadas de el diseño del lenguaje, por lo que todos los excepciones excepciones sin marcar. Ellos embargo, no dejan espacio para una aplicación de excepciones comprobadas en un momento posterior.)

Personalmente, encuentro excepciones comprobado que es útil única cuando su API tiene la costumbre de coger todas las excepciones y volver a lanzarlos como algo Apropiado para tu capa de abstracción Por ejemplo, una memoria caché de objetos en memoria que utiliza un disco o SQL backend para almacenar datos nunca debe arrojar IOException o SQLException; en su lugar, debe arrojar (y declarar) alguna excepción definida por el usuario como CacheFailureException o similar.

Además, puede encontrar el artículo de Ned Batchelder Exceptions in the Rainforest esclarecedor en relación con esta pregunta.

Answer 2

Java no requiere que escriba throws Exception en una declaración de función, por lo que no es "necesario" en general. Requiere que declare las excepciones que puede lanzar la función, que podría no ser excepciones en absoluto, o solo excepciones de tiempo de ejecución. De hecho, usar throws Exception es probablemente un signo de codificación perezosa, ya que actúa como un catch-all desinformativo.

edición — bien ahora que ha editado la pregunta, la respuesta que está buscando (como han dicho otros) es que Java tiene el concepto de "controladas" excepciones. Fue simplemente una decisión de diseño, para supuestamente mejorar la calidad del código. Probablemente no ayude mucho a la larga; no puedes arreglar un codificador incorrecto con un truco de lenguaje.

Answer 3

Declara que el método puede generar una excepción y permite a los desarrolladores y sus herramientas asegurarse de que hayan considerado esa posibilidad.

Sin embargo, la pregunta es imprecisa. La declaración solo es obligatoria cuando la excepción es una excepción "marcada". Y luego, se debe declarar un tipo más específico de excepción. Lanzar un java.lang.Exception es un estilo pobre.

Las excepciones en tiempo de ejecución, es decir, las excepciones generadas por el tiempo de ejecución cuando se encuentran errores específicos, no son requeridas por declararse. Se deben lanzar excepciones de tiempo de ejecución cuando el error se puede evitar mediante una mejor programación, y no depende de las condiciones ambientales en el tiempo de ejecución.

Answer 4

Hay dos tipos de excepciones

1. excepciones comprobadas
2. excepciones sin control

La cláusula throws indica qué excepciones son lanzadas por el método de manera que la persona que llama puede manejar estos en el comprueban código o tendrían que agregar la cláusula throws para que al final alguien tenga que manejar estas excepciones.

Answer 5

Java es un lenguaje muy organizado que evita en muchas situaciones que el usuario inexperto se pierda algo relevante o de importancia, al menos para que los errores puedan mostrarse más adelante con una buena pista o explicación de lo que falta. Obligar a que menciones las excepciones en una declaración de función/método es una forma de mantener esa política y, al mismo tiempo, una forma de permitirte definir tus propias excepciones específicas y ponerlas en práctica.

Answer 6

El objetivo de declarar excepciones en Java era forzar al programador a manejar los errores que pueden surgir al ejecutar el programa. Sin embargo, la experiencia ha demostrado que, en muchos casos, 'manipulación' de los programadores de las excepciones realmente no manejar las excepciones pero en cambio no les hizo caso:

 
void writeToFile() { 
    try { 
     ... 
    } catch (IOException ex) { 
     // Nothing here 
    } 
} 

Así que en lenguas más reciente que la de Java los diseñadores prefieren no comprobar excepciones , de modo que los programas sin verificación de errores al menos se bloqueen con un seguimiento de pila significativo, por lo que tendría un error fácil de depurar en lugar de un "misterioso" mal funcionamiento de su programa.

Personalmente me gusta excepciones comprobado en Java porque:

• No maneje mal excepciones.
• Las excepciones me hacen ser consciente de los posibles problemas que mi código podría tener.
• El código está mejor documentado de esa manera.

pero puedo entender las excepciones sin marcar. La mayoría de las veces que manejo una excepción es registrarla, envolverla con alguna subclase de RuntimeException y volver a lanzar, ya que solo pueden ser causadas por errores/configuración incorrecta/implementación interrumpida. Me gusta usar excepciones marcadas solo para infracciones de reglas comerciales.

Answer 7

Como he entendido la razón de ser presentado por los diseñadores de Java, las situaciones de error en general se colocan en dos categorías:

• Los que son no fatal y el código de llamada con razón debe ser capaz recuperarse de. FileNotFoundException al leer archivos de formulario y IOExceptions cuando se trabaja con sockets.
• Los que son fatales si no pueden ser esperados por el código de llamada. Esto incluye ArrayIndexOutOfBoundsException y ArithmeticException (cuando se divide por cero).