Hay muchos tipos de errores: errores en tiempo de compilación, errores lógicos, errores en tiempo de ejecución y errores generados. Nos centraremos en los errores en tiempo de compilación en esta sección y revisaré los demás en las siguientes secciones.
Los errores en tiempo de compilación suelen ser errores sintácticos: debemos verificar los nombres de sus funciones, los tokens del lenguaje (corchetes, paréntesis, puntos, comas), la aridad de sus funciones, etc. Aquí hay una lista de algunos de los mensajes de error comunes en tiempo de compilación. y posibles soluciones en caso de que las encuentre:
module.beam: Module name 'madule' does not match file name 'module'
El nombre del módulo que ingresó en el atributo -module no coincide con el nombre del archivo.
./module.erl:2: Warning: function some_function/0 is unused
No has exportado una función, o el lugar donde se usa tiene el nombre o aridad incorrectos. También es posible que haya escrito una función que ya no es necesaria. ¡Comprueba tu código!
./module.erl:2: function some_function/1 undefined
La función no existe. Ha escrito el nombre o la aridad incorrectos en el atributo -export o al declarar la función. Este error también se genera cuando la función dada no se pudo compilar, generalmente debido a un error de sintaxis, como olvidar finalizar una función con un punto.
./module.erl:5: syntax error before: 'SomeCharacterOrWord'
Esto sucede por diversas razones, a saber, paréntesis no cerrados, tuplas o terminación de expresión incorrecta (como cerrar la última rama de un caso con una coma). Otras razones pueden incluir el uso de un átomo reservado en su código o caracteres Unicode que se convierten de manera extraña entre diferentes codificaciones (¡lo he visto suceder!)
./module.erl:5: syntax error before:
¡Muy bien, ese ciertamente no es tan descriptivo! Esto suele ocurrir cuando la terminación de su línea no es correcta. Este es un caso específico del error anterior, así que mantente atento.
./module.erl:5: Warning: this expression will fail with a 'badarith' exception
Erlang tiene que ver con la escritura dinámica, pero recuerde que los tipos son fuertes. En este caso, el compilador es lo suficientemente inteligente como para descubrir que una de sus expresiones aritméticas fallará (digamos, llama + 5). Sin embargo, no encontrará errores tipográficos mucho más complejos que eso.
./module.erl:5: Warning: variable 'Var' is unused
Declaraste una variable y nunca la usaste después. Esto podría ser un error en su código, así que verifique lo que ha escrito. De lo contrario, es posible que desee cambiar el nombre de la variable a _ o simplemente anteponerle un guión bajo (algo como _Var) si cree que el nombre ayuda a que el código sea legible.
./module.erl:5: Warning: a term is constructed, but never used
En una de tus funciones, estás haciendo algo como construir una lista, declarar una tupla o una función anónima sin vincularla a una variable ni devolverla. Esta advertencia te indica que estás haciendo algo inútil o que has cometido algún error.
./module.erl:5: head mismatch
Es posible que tu función tenga más de un encabezado y cada uno de ellos tenga una aridad diferente. No olvide que una aridad diferente significa funciones diferentes y no puede intercalar declaraciones de funciones de esa manera. Este error también aparece cuando inserta una definición de función entre las cláusulas principales de otra función.
./module.erl:5: Warning: this clause cannot match because a previous clause at line 4 always matches
Una función definida en el módulo tiene una cláusula específica definida después de una general. Como tal, el compilador puede advertirle que ni siquiera necesitará ir a la otra rama.
./module.erl:9: variable 'A' unsafe in 'case' (line 5)
Estás usando una variable declarada dentro de una de las ramas de un caso... o fuera de él. Esto se considera inseguro. Si desea utilizar dichas variables, sería mejor que hiciera MyVar = case... of...
Esto debería cubrir la mayoría de los errores que obtiene en tiempo de compilación en este momento. No hay demasiados y la mayoría de las veces la parte más difícil es encontrar qué error causó una enorme cascada de errores enumerados en otras funciones. Es mejor resolver los errores del compilador en el orden en que fueron reportados para evitar ser engañado por errores que en realidad pueden no ser errores.
