#100DaysOfCode _ #Day55
Haciendo frente a los errores de código
Una de las cosas a las que debemos acostumbrarnos estando en el mundo del desarrollo o programación, es a hacer frente a errores.
Más aún los que somos Junior, pero nadie se escapa de esto.
Es raro la vez que una implementación, un programa, un código o lo que sea que llevemos a cabo, funcione a la primera. Muy raro. Y lo más común es que obtengamos gran cantidad de fallos durante el camino, que deberemos ir solventando.
La clave aquí es la de no frustrarse y saber qué hacer cuando ocurre esto.
A pesar de mi escasa experiencia en este mundo, yo ya me he enfrentado a varias situaciones en las que, pensando que mi código estaba perfecto, lo he ejecutado y me he topado con un bonito error en la consola
O, lo que es peor, con uno de los llamados “silent bugs”: no es directamente un error en la consola, es un error interno de nuestro código que impide que se ejecute como teníamos planeado.
Y claro, se te queda una cara como la del colega…
Visto esto, podemos determinar que hay dos categorías principales de errores (a la que voy a añadir una más, si se me permite):
Errores tipo 1: Aquellos que impiden que nuestro programa se ejecute
Aparecen referenciados en la consola, con su ruta indicada, el tipo de error y una breve descripción.
Los errores más comunes de esta categoría son:
- SyntaxError. Revisa la sintaxis de tu código, puede que te hayas equivocado en algún elemento…
- ReferenceError. ¿Has definido correctamente las variables a las que estás llamando?
- TypeError. ¿Estás teniendo en cuenta el tipo de variable con la que estás trabajando?
Como digo, estos son los más comunes, pero la lista es más amplia…
Errores tipo 2: Los que permiten la ejecución del programa pero permanecen silentes en el mismo.
Deberemos depurar el código para dar con el error, ya que la ejecución no se paraliza pero no obtenemos el resultado que esperábamos.
Cabe tener muy en cuenta temas como el hoisting y el alcance de las variables en este tipo de errores, porque puede que hayamos pasado por alto algo importante durante la codificación que nos impide conseguir lo que queríamos.
Es importante para ello ir chequeando que los parámetros que utilizamos son los correctos y que la referencia a los mismos (y al valor de sus variables) se obtiene de la forma que deseamos. Para ello siempre nos acompaña el arma infalible de …
console.log(...);Errores tipo 3: Los que creamos nostros mismos…
( NOTA: los errores también son objetos)
Abre la consola e introduce lo siguiente:
console.log(Error('Este tipo de error no para la ejecución de código'));
console.log('¿Ves como NO lo hace?');Echale un vistazo al resultado (…)
y ahora introduce:
throw Error('Este tipo de error sí que paraliza las siguientes ejecuciones');
console.log('No me voy a mostrar');
Son dos tipos de errores que podemos generar voluntariamente en nuestro código usando el objeto Error.
“try” and “catch”
Hay veces que no podemos prevenir que los errores ocurran, pero debemos tener un “plan B” para estos casos. Aquí es donde entra el término “error handling” que en castellano viene a ser algo así como “manejo de errores”.
Se configuran mediante la siguiente sintaxis:
try{(..)}catch(e){(..)}Y funciona de la siguiente manera:
Se intenta ejecutar el código introducido en try{}, en caso de que arroje un error, este es recogido por catch y procesado según indiquemos en {}.
Un ejemplo:
Si hacemos esta reasignación a la variable “value” definida como constante, nos arrojará un “TypeError” y paralizará la ejecución del código.
Si usamos este sistema de manejo de errores, podemos “capturar” dicho error y bloquearlo para que el usuario pueda ser o no consciente de él, pero sin afectar a la ejecución del programa.
¿Y para qué quiero capturar los errores? Si sé que va a haber un error no lo cometeré…
Cierto, pero cuando hacemos una petición a una API externa de la que desconocemos realmente su funcionamiento y queremos asegurarnos de que nuestro programa funcione aunque esta falle, debemos usar el manejo de errores de la forma anteriormente expuesta.
Así nos aseguraremos de que, a pesar del posible fallo, lo tenemos todo más o menos controlado.
Keep Coding!
