La semana pasada te di una lista de 10 razones por las que tu código no compila. Pensaba que con diez bastaría, pero me cuando me puse con la faena no dejaban de ocurrírseme nuevas razones.
More...
Así que, aquí tienes, tachán tachán:
Otras 10 razones por las que tu código no compila
Estas listas las hago, en primer lugar, para que las tengas en cuenta a la hora de enfrentarte al examen de certificación de Java, donde te encontrarás con pedazos de código con indentaciones irregulares dentro de un mismo pedazo, sin sintaxis resaltada, errores más o menos sutiles y con claros ejemplos de lo que NO son buenas prácticas. Pero, con todo, quizá te preguntes ¿hay alguien que programe sin utilizar un IDE?
Lo cierto es que sí. Son pocos, pero los hay. Si le echas un vistazo al artículo publicado por Eugen Paraschiv en Baeldung, The State of Java in 2018, verás en el punto 5 que un número muy pequeñito de programadores, el 1,6% no utilizan ni IntelliJ (55,4%), ni Eclipse (38%) ni Netbeans (5,1%). Estoy seguro de que algunos de ellos programan con el bloc de notas (y seguro que son unos fieras).
(Por cierto, te regalo un curso de IntelliJ si te suscribes.)
Pero me estoy yendo por las ramas. Así que, al lío:
11._ Un tipo primitivo no puede ejecutar un método
Así, tal cual.
Una referencia que apunte a un objeto puede ejecutar cualquier método de su clase. Una referencia cuyo valor asignado sea null puede ejecutar un método estático de su clase.
Un tipo primitivo no puede ejecutar un método.
12._ Ni no existe la posibilidad de una IOException, no puedes cazarla
Debe existir la posibilidad de que se lance una IOException en el código de un bloque try para que dicha excepción aparezca en un catch.
Lo mismo ocurre con FileNotFoundException, que es una subclase.
Si existe la posibilidad de que se lance un excepción chequeada (subclase de Exception, pero no de RuntimeException) ha de utilizarse siempre un bloque try/catch o incluirla en la signatura del método (metodo() throws IOException {}). De lo contrario, ya sabes: el código no compila.
13._ Cuidado con los arrays[]
Si en el examen el código no compila y hay un array[] instanciado, échale un vistazo, porque quizá haya un error:
Tranquilo, te pongo ejemplos.
14._ Uso correcto de *=, /=, -=, +=
int z += 4; // Esto no compila.
Como z aún no tiene un valor asignado, esta línea no compila.
15._ Presta atención a las interfaces
Recuerda que las variables de una interfaz son siempre public, static y final. Al ser siempre así, estas tres palabras clave pueden omitirse.
Los métodos son siempre public y, si no se indica que sean default o static (ambos con cuerpo), son abstract (sin cuerpo). La palabra clave abstract también se puede omitir.
En este ejemplo, las dos interfaces son exactamente iguales, pero en la segunda he omitido todo lo que se podía omitir. Los métodos estáticos de las interfaces no se heredan y, si al implementar dos interfaces ambas contienen un método con el mismo nombre, hay que sobreescribirlos (con un solo método). De lo contrario, el código no compila.
Recuerda: class extends class, interface extends interface, class implements interface.
Échale un vistazo a este otro artículo que escribí sobre herencia.
16._ Memoriza el orden de preferencia de los operadores
El orden de preferencia de los operadores es algo que tienes que tener muy en cuenta, ya que de lo contrario puede parecerte que un código que no compila es válido.
Mira este ejemplo:
Como ves en el ejemplo, el punto tiene preferencia sobre el cast. Por ello, para que el código compile, hay que poner el cast entre paréntesis, para que así el método se ejecute.
Estoy aprendiendo a analizar código #Java para pasar el examen oficial de certificación #OCA
17._ Un bucle no puede evaluar false
Un bucle do o for (pero no do-while) no puede utilizar la palabra clave false, ni puede utilizar una variable final en su evaluación, si el resultado de esta es falso.
Esto se debe a que, si la evaluación es explícitamente false, el código que contiene no llega a ejecutarse.
18._ Si algo es imposible, el compilador no lo aceptará
El código no compila si el compilador considera que algo es imposible.
Por ejemplo, si tienes dos objetos i y j de tipos diferentes, i == j no compila (nunca puede ser verdadero).
19._ Un break con etiqueta necesita una etiqueta
Un break con etiqueta solo puede aparecer dentro de un bucle que se encuentra justo a continuación de la etiqueta a la hace referencia.
20._ Cuidado al instanciar clases envoltorio
¿Sabes cómo instanciar una clase envoltorio? O, de manera más concreta, ¿de cuántas maneras le puedes asignar el valor 1 a una variable de tipo short?
En el siguiente ejemplo, ¿ves algún error?
Si pruebas a ejecutarlo, verás que sí lo hay. Resulta que el constructor de la clase Short solo admite como argumento una variable short o una String, y ya sabes que todos los números enteros son, de manera predeterminada, int.
Por esta razón, new Short(1); no compila, pero sí lo hacen new Short((short)1); o new Short("1");.
Y esto sigue sin ser todo, amigos
Con este artículo cierro (por ahora) la lista de puntos a tener en cuenta a la hora de analizar el código en el examen, pero esto no significa que la lista esté completa. Investiga y, si encuentras otro caso en el que el código no compila pero, de manera intuitiva, esperabas que lo hiciera, ¡compártelo en los comentarios! 🙂
