Después de de esta larga selección de datos solucionamos este apuro que presentan muchos los lectores. Te ofrecemos la respuesta y nuestro objetivo es resultarte de mucha ayuda.
Solución:
En Java, como sabrá, las excepciones se pueden clasificar en dos: Una que necesita la throws cláusula o debe manejarse si no especifica uno y otro que no lo hace. Ahora, vea la siguiente figura:
En Java, puede lanzar cualquier cosa que amplíe el Throwable clase. Sin embargo, no es necesario especificar un throws cláusula para todas las clases. Específicamente, las clases que son una Error o RuntimeException o cualquiera de las subclases de estos dos. En tu caso Exception no es una subclase de un Error o RuntimeException. Por lo tanto, es una excepción marcada y debe especificarse en el throws cláusula, si no maneja esa excepción en particular. Es por eso que necesitabas el throws cláusula.
Desde el tutorial de Java:
Una excepción es un evento, que ocurre durante la ejecución de un programa, que interrumpe el flujo normal de las instrucciones del programa.
Ahora, como sabe, las excepciones se clasifican en dos: marcadas y no marcadas. ¿Por qué esta clasificación?
Excepción marcada: Se utilizan para representar problemas que se pueden recuperar durante la ejecución del programa. Por lo general, no son culpa del programador. Por ejemplo, un archivo especificado por el usuario no es legible, o no hay conexión de red disponible, etc., en todos estos casos, nuestro programa no necesita salir, sino que puede tomar acciones como alertar al usuario, o entrar en una reserva. mecanismo (como trabajar sin conexión cuando la red no está disponible), etc.
Excepciones sin marcar: De nuevo, se pueden dividir en dos: errores y excepciones en tiempo de ejecución. Una de las razones por las que no se controlan es que son numerosos en número y, si se requiere manejarlos, se saturará nuestro programa y se reducirá su claridad. La otra razón es:
-
Excepciones de tiempo de ejecución: Suelen ocurrir debido a una falla del programador. Por ejemplo, si un
ArithmeticExceptionde la división por cero se produce o unaArrayIndexOutOfBoundsExceptionocurre, es porque no somos lo suficientemente cuidadosos en nuestra codificación. Suelen ocurrir debido a algunos errores en la lógica de nuestro programa. Por lo tanto, deben borrarse antes de que nuestro programa entre en modo de producción. Están desmarcados en el sentido de que nuestro programa debe fallar cuando se produzca, para que los programadores podamos resolverlo en el momento del desarrollo y testeo. -
Errores: Los errores son situaciones de las que normalmente el programa no puede recuperarse. Por ejemplo, si un
StackOverflowErrorocurre, nuestro programa no puede hacer mucho, como aumentar el tamaño de la pila de llamadas a funciones del programa. O si unOutOfMemoryErrorocurre, no podemos hacer mucho para aumentar la cantidad de RAM disponible para nuestro programa. En tales casos, es mejor salir del programa. Por eso no se controlan.
Para obtener información detallada, consulte:
- Excepciones no controladas: la controversia
- El requisito de capturar o especificar
Java requiere que maneje o declare todas las excepciones. Si no está manejando una excepción usando un bloque try / catch, entonces debe declararse en la firma del método.
Por ejemplo:
class throwseg1
void show() throws Exception
throw new Exception();
Debe escribirse como:
class throwseg1
void show()
try
throw new Exception();
catch(Exception e)
// code to handle the exception
De esta forma puede deshacerse de la declaración “throws Exception” en la declaración del método.
los throws Exception La declaración es una forma automatizada de realizar un seguimiento de los métodos que pueden generar una excepción por razones anticipadas pero inevitables. La declaración suele ser específica sobre el tipo o tipos de excepciones que se pueden generar, como throws IOException o throws IOException, MyException.
Todos tenemos o eventualmente escribiremos código que se detiene inesperadamente e informa una excepción debido a algo que no anticipamos antes de ejecutar el programa, como la división por cero o el índice fuera de los límites. Dado que el método no esperaba los errores, no podían “detectarse” ni manejarse con una cláusula try catch. Cualquier usuario desprevenido del método tampoco conocería esta posibilidad y sus programas también se detendrían.
Cuando el programador sabe que pueden ocurrir ciertos tipos de errores pero le gustaría manejar estas excepciones fuera del método, el método puede “lanzar” uno o más tipos de excepciones al método de llamada en lugar de manejarlas. Si el programador no declaró que el método (podría) lanzar una excepción (o si Java no tenía la capacidad de declararlo), el compilador no podría saberlo y dependería del futuro usuario del método conocerlo, captura y maneja cualquier excepción que el método pueda generar. Dado que los programas pueden tener muchas capas de métodos escritos por muchos programas diferentes, resulta difícil (imposible) realizar un seguimiento de los métodos que pueden generar excepciones.
Aunque Java tiene la capacidad de declarar excepciones, aún puede escribir un nuevo método con excepciones no controladas y no declaradas, y Java lo compilará y podrá ejecutarlo y esperar lo mejor. Lo que Java no le permitirá hacer es compilar su nuevo método si usa un método que ha sido declarado como lanzando excepciones, a menos que maneje las excepciones declaradas en su método o declare que su método arroja lo mismo excepción (es) o si hay varias excepciones, puede manejar algunas y lanzar el resto.
Cuando un programador declara que el método genera un tipo específico de excepción, es solo una forma automatizada de advertir a otros programadores que utilizan el método de que es posible una excepción. Luego, el programador puede decidir manejar la excepción o pasar la advertencia declarando que el método de llamada también lanza la misma excepción. Dado que el compilador ha sido advertido de que la excepción es posible en este nuevo método, puede verificar automáticamente si los futuros llamadores del nuevo método manejan la excepción o la declaran y obligan a que suceda una u otra.
Lo bueno de este tipo de solución es que cuando el compilador informa Error: Unhandled exception type java.io.IOException da el archivo y el número de línea del método que se declaró para lanzar la excepción. A continuación, puede optar por simplemente pasar la pelota y declarar que su método también “lanza IOException”. Esto se puede hacer hasta el método principal, donde luego haría que el programa se detuviera e informara la excepción al usuario. Sin embargo, es mejor detectar la excepción y tratarla de una manera agradable, como explicar al usuario lo que sucedió y cómo solucionarlo. Cuando un método detecta y maneja la excepción, ya no tiene que declarar la excepción. La pelota se detiene allí, por así decirlo.
Reseñas y valoraciones del artículo
Agradecemos que quieras añadir valor a nuestro contenido informacional colaborando tu experiencia en las notas.