Advertencia variable de bloque de captura en Java

Question

Intento que mi código se compile sin errores ni advertencias como práctica estándar. Sin embargo, hay una advertencia molesta que sé cómo manejar en .NET pero no en Java. Decir que tengo un bloque de código como este:

try { 
     FileInputStream in = new FileInputStream(filename); 
     return new Scanner(in).useDelimiter("\\A").next(); 
    } catch (FileNotFoundException ex) { 
     LOG.log(Level.SEVERE, "Unable to load file: {0}", filename); 
     return null; 
    } 

recibo una advertencia de que la variable ex no se utiliza. Ahora, realmente no tengo un uso para ex, no quiero ex, pero no sé qué hacer al respecto. En .NET podría hacer:

catch (FileNotFoundException) 

sin la variable y se compilará y ejecutará sin ningún error.

¿Cómo se manejaría esta situación en Java? Sé que podría crear una variable local y establecerla en ex, pero parece una solución estúpida y derrochadora para solucionar una advertencia que realmente no es necesaria.

Answer 1

No hay una manera clara de "marcar ex como se usa" en Java, excepto al usarlo.

Tenga en cuenta, sin embargo, que de acuerdo a un its documentationFileNotFoundException también se puede generar cuando "[...] el archivo existe, pero por alguna razón es inaccesible, por ejemplo, cuando se hace un intento para abrir un solo lectura archivo para escribir ".

Por lo tanto, sugiero que haga use la excepción imprimiendo también el mensaje de la excepción.

Soy consciente de que esto no responde a la pregunta general, pero no puedo pensar en una excepción de la cual no registraría al menos información sobre cuando ocurra.

Answer 2

Utilice la anotación @SuppressWarnings("unused").

Consulte también:

• Annotations tutorial
• Supported Values for @SuppressWarnings

Answer 3

Iniciar la excepción. Siempre es útil de todos modos al perseguir un error.

Answer 4

Si compilo ese código con javac, no aparece una advertencia, por lo que o bien está usando un compilador diferente o diferentes configuraciones, supongo que se usa un IDE con una configuración especial para las variables no utilizadas.

En eclipse, apago estas advertencias linewise con anotaciones, en este caso: @SuppressWarnings ("unused") en la línea anterior.

Answer 5

Debe registrar la excepción. Según la API FileInputStream, se puede generar un FileNotFoundException "si el archivo no existe, es un directorio en lugar de un archivo normal, o por algún otro motivo no se puede abrir para su lectura". Si se encuentra con ese problema, tener más detalles en su archivo de registro (como el seguimiento de la pila) lo hará más fácil de corregir.

Answer 6

La advertencia es una advertencia IDE, debería poder desactivarla.

Sin embargo, hay muchas razones por las que se puede lanzar FileNotFoundException, querrá saber el motivo en este caso.

IntelliJ reconoce ignore o ignored como una excepción deliberadamente ignorada o un bloque catch no vacío como aceptable según su configuración.

Answer 7

Básicamente, usted es SOL (tiene que declarar la variable y absorber la advertencia) porque JAVA es un poco maníaco-depresivo, o al menos niñera, en su enfoque hacia el desarrollador; este es otro ejemplo más. JAVA te hace declarar la variable catch incluso si nunca intentas usarla. Eso significa que tiene una variable sin usar esperando que cause un problema. Si bien hubo muchos comentarios sobre "necesita trabajar con esta variable de excepción", esos comentarios se pierden el sentido de la pregunta. La pregunta es "¿cómo no obtengo esta advertencia de variable no utilizada?", El ejemplo usa la excepción FileNotFound, pero podría ser una excepción. La pregunta no era sobre la excepción FileNotFound, sino sobre la advertencia de la variable no utilizada.

El tipo de excepción no es importante para esta pregunta. Por ejemplo, tengo una clase que administra buffers de datos. Puede arrojar una excepción por algunas razones, una de las cuales es que el buffer de datos está lleno. Entonces, si trato de poner datos en el búfer completo, mi función puede recibir esa excepción. Es la única excepción que puede recibir en esta situación. Una función que tengo que utiliza esta clase detecta la excepción y expande el búfer. No le importa la variable de excepción, no registra la excepción, procesa la excepción y continúa. En lugar de la excepción, podría devolver un indicador que indica que el búfer está lleno, pero el sistema de procesamiento de excepciones no funciona (hay otras rutinas en el sistema donde esta excepción es un error y las manejo con el registro y los mensajes al usuario) , etc.)

Entonces, podría configurar el IDE para ignorar la advertencia de la variable no utilizada. Pero esa no es una buena idea porque hay momentos en los que no usar una variable indica un problema real (me perdí una pieza de código o tal vez olvidé terminar un comentario en bloque o algo así). O, como mínimo, tengo un código no utilizado que podría agregar confusión en el futuro. Podría suprimir la advertencia, pero eso es solo una tontería. El resultado final es que tengo que poner una variable sin usar, documentar por qué no se usa y dar un rodeo para suprimir la advertencia (por lo que QA no se queja) porque JAVA quiere protegerme de mí mismo.

<rant> 

Aquí es donde tengo un gran problema con JAVA. JAVA afirma que es un lenguaje de programación serio para ser utilizado por profesionales serios en proyectos serios. Sin embargo, luego hacen la suposición de que estos mismos profesionales serios siempre cometen errores estúpidos y necesitan ser protegidos de esos errores. Es casi como decirles a los cirujanos que no pueden usar un bisturí porque podrían cortarse a sí mismos. Si está creando un lenguaje de programación de juguetes para aficionados, coloque todas las protecciones que desee. Pero, si pretende hacer un lenguaje para profesionales, brinde a los profesionales las herramientas que necesitan para hacer su trabajo. Son profesionales, dales herramientas profesionales. Cosas como forzar la definición de una variable no utilizada, no permitir sobrecargas al operador, no tener primitivas sin signo, y básicamente tratar a las clases de usuarios como ciudadanos de segunda clase limitan el conjunto de herramientas e indican un punto de vista de que los ingenieros profesionales no son tan profesionales. No me importan las advertencias: ayudan a que el proceso de desarrollo sea más rápido. No me gusta la falta de un conjunto completo de herramientas. Eso causa problemas, kludges y una nueva fuente de errores.

De todos modos, lo siento por la diatriba

</rant>