10 razones por las que tu código Java no compila (I)

Si tu código Java no compila, ¿sabes analizarlo? Pero sin utilizar un IDE, oye. Así, cualquiera.

En este ejemplo, en el código aparece una llamada al método moveHistorial(boolean), pero sin ningún argumento. Aunque aquí es fácil verlo, ya que el método llamado se encuentra justo a continuación, en un proyecto más grande no va a estar tan a la vista. Pero, de todas formas, el IDE te lo chiva.

En el examen, en cambio, no vas a poder utilizar ningún IDE: vas a tener delante de ti un fragmento de código, con varias opciones entre las que escoger, y es muy posible que una de ellas sea "el código no compila", así, en general, sin especificar una línea. Entonces, ¿qué?

Como ya te he comentado en otros artículos, es posible que en el examen te topes con una pregunta que parezca orientada hacia las lambdas pero que, en realidad, te esté poniendo a prueba, porque el código lanza una excepción antes de llegar a la lambda.

Con los errores de compilación no pasa esto. Es decir, si todas las opciones de respuesta a la pregunta dan por supuesto que el código compila, es porque va a compilar. No obstante, es posible que te encuentres con opciones como las siguientes:

Puede que te aparezcan varias opciones con distintos números de línea en una misma pregunta. En este caso, fíjate si las líneas citadas compilan.

En estos dos casos deberás revisar todo el código; la primera opción, "el código no compila", deja abierta la posibilidad; la segunda, "ninguna de las anteriores", deja la puerta abierta a cualquier cosa (y es una opción bastante jodida, porque te obliga a pensar en todo).

Supongamos, entonces, que te encuentras con una de esas opciones en el examen. A partir de ese momento tienes que analizar el código como si fueras el compilador. ¿Y en qué se fija el compilador? A continuación te enumero diez puntos en lo que te tendrás que fijar en el examen de certificación para saber si tu código compila.

Fíjate que en el código que estás analizando no haya ninguna llamada a un método que no existe.

Asegúrate de que la llamada reproduce correctamente el nombre del método, y que la lista de argumentos de la llamada coincida con la lista de parámetros del método. Ten cuidado con los métodos sobrecargados y con los métodos heredados; no olvides que no se puede llamar un método no estático desde un método estático.

En relación con el punto anterior, ¿aparecen en el texto métodos para los que es necesario hacer un import? Fíjate si el código está numerado. Si lo está, deberían estar todos los import necesarios.

Fíjate que todas las variables o referencias que se utilizan estén declaradas. La declaración ha de ser anterior a su uso.

Aquí, depende. Es posible, en ciertas ocasiones, hacer uso de una variable a la que no se le ha asignado un valor, o de una referencia a la que no se le ha asignado un objeto.

Ten en cuenta que el compilador no tiene en cuenta el valor asignado a una variable, si esta no está marcada como final.

Si la variable forma parte de un objeto (es decir, es un campo de clase), toma un valor predeterminado si no le asigna ninguno. Así, de un modo u otro siempre contiene un valor.

Si la variable es local, es decir, si aparece dentro de un método, no posee un valor de manera predeterminada. Si existe una variable sin asignar, todo irá bien siempre y cuando no se haga nada con esa variable. En el momento en el que quieras utilizarla, aunque sea para imprimirla, el código no va a compilar.

Así, la asignación de una variable local ha de ser explícita. Si a la variable se le asigna un valor de manera dinámica y según una condición, esta asignación tampoco le vale al compilador, aunque la condición se cumpla. 

Puedes resolver este problema marcando como final la variable que se evalúa en la condición (en ese caso, el compilador sí tiene en cuenta su valor) o asígnandole otro valor a la variable de no cumplirse la condición (así, en cualquier caso se le asigna un valor).

Con una referencia puede ocurrir tres cosas:

Me refiero a que parte del código no llega a ejecutarse en ningún caso. Por ejemplo, si un método devuelve un valor, no puede haber código después del return. Si hay un return dentro de un switch o una estructura if/else, habrá de cumplirse una de las dos condiciones que siguen:

Ve probando varias combinaciones. Por supuesto, existen al menos tres excepciones a esta regla:

De nuevo, tenemos dos casos: si el método devuelve un tipo primitivo, o si devuelve una referencia a un objeto. En pocas palabras, el método puede devolver el valor que aparece explícito en su signatura, u otro más pequeño. A continuación te explico qué quiero decir con eso de más pequeño.

Un método ha de devolver o el mismo tipo primitivo que aparezca en su signatura, o un tipo compatible. Es decir, si devuelve un int, no puede devolver un double. En cambio, si devuelve un double, sí puede devolver un int. Échale un ojo a los artículos que he publicado sobre tipos primitivos.

No obstante, si la devolución es la clase envoltorio de un primitivo (Integer, Double, Boolean, Long, Float, Character, Short, Byte) solo podrás devolver ese mismo primitivo o su envoltorio. Es decir, si la devolución es Double, no es válido devolver un int. Solo double o Double.

Un método ha de devolver una referencia del mismo tipo que la que aparece en su signatura, o de una subclase. Es decir, si según la signatura el método devuelve List<String>, es válido devolver ArrayList<String>.

Este punto, el número 6, también es válido en lo que respecta a los argumentos que admite un método: los argumentos han de ser del mismo tipo que los parámetros de la signatura, o compatibles. Además, han de aparecer en el mismo orden.

Este punto está vinculado al anterior. Resulta que, esta vez, la signatura del método especifica que devuelve un double; el método devuelve un int, y la devolución se asigna a una variable de tipo int. Resultado: no compila.

De nuevo, no puedes asignar un tipo primitivo a un objeto envoltorio de otro primitivo: no puedes asignar int a Double.

¿Saves por qué no compila en este caso?

No se pueden reasignar una variable o una referencia marcados como final.

En cambio, sí puedes modificar, por ejemplo, el contenido de un List marcado como final. Lo que no puedes es asignar su referencia a otro List.

El constructor predeterminado solo existe cuando no existe un constructor explícito. Es decir, si la clase no posee un constructor, es posible instanciar esa clase mediante una llamada a un constructor sin argumentos.

En este ejemplo, como ves, hay un método que parece ser un constructor, pero que no lo es. Para instanciar la clase hay que utilizar el constructor predeterminado. Parece que este ejemplo de código Java no compila, pero sí que lo hace.

Recuerda que el constructor NUNCA tiene un valor de devolución.

En los casos en los que tengas delante varias clases en una jerarquía de herencia, recuerda que las clases se instancian desde la superclase hacia abajo, y que cada constructor posee una llamada, ya sea implícita (super();) o explícita, al constructor de la superclase.

El constructor implícito de C hace una llamada al constructor sin argumentos de B. Como el constructor de A tiene un parámetro, la llamada al constructor de A desde el constructor de B ha de ser explícito.

Este punto está bien claro: cuando tengas varios if/else o bucles anidados, fíjate en que no falte ninguna llave de cierre ni paréntesis; que todos los punto y coma estén en su sitio al final de cada línea, es decir, que la sintaxis sea correcta.

¿Qué te ha parecido la lista? ¿Sabes ya por qué tu código Java no compila? Tranquilo, la semana que viene continuaré con esta lista, ya que me he dejado varios casos más en el tintero. Mientras tanto, practica todos estos ejemplos, ¡y acostúmbrate a leer mucho código!