Lanzar una excepcion con Throw dentro de un callback asincrono no va a funcionar… Solo nos va a funcionar en n bloque de codigo sincrono
Conocer los conceptos básicos de NodeJS
Instalación de Node.js
Node: orígenes y filosofía
EventLoop: asíncrona por diseño
Monohilo: implicaciones en diseño y seguridad
Configurar las variables de entorno en Node.js
Herramientas para ser más felices: Nodemon y PM2
Cómo manejar la asincronía
Callbacks
Callback Hell: refactorizar o sufrir
Promesas
Async/await
Entender los módulos del core
Globals
File system
Console
Errores (try / catch)
Procesos hijo
Módulos nativos en C++
HTTP
OS
Process
Utilizar los módulos y paquetes externos
Gestión de paquetes: NPM y package.json
Construyendo módulos: Require e Import
Módulos útiles
Datos almacenados vs en memoria
Buffers
Streams
Conocer trucos que no quieren que sepas
Benchmarking (console time y timeEnd)
Debugger
Error First Callbacks
Manejar herramientas con Node
Scraping
Automatización de procesos
Aplicaciones de escritorio
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Carlos Hernández
Aportes 48
Preguntas 3
Lanzar una excepcion con Throw dentro de un callback asincrono no va a funcionar… Solo nos va a funcionar en n bloque de codigo sincrono
Un patrón que se sigue siempre en cualquier lenguaje y programa de devs es Error First Callbacks, esto quiere decir que siempre que tengamos un callback el primer parámetro debería ser el error.
😭 Esto se usa por la convención de que todo puede fallar.
Otro patrón típico es tener el callback es tener en el callback como la última función que se pasa. Aunque depende del caso.
function asincrona(callback) {
setTimeout(() => {
try {
let a = 3 + w
callback(null, a)
} catch (error) {
callback(error)
}
}, 1000)
}
asincrona((err, dato) => {
if (err) {
console.error('Tenemos un error')
console.error(err)
return false
// throw err
}
console.log(`Todo ha ido bien, mi dato es ${dato}`)
})
Si el V8 es el corazón de Nodejs, los callbacks son sus venas. 💚
Los Error First Callbacks se utilizan para pasar primero el error y los datos posteriormente. Entonces, puedes verificar el primer argumento, es decir, el objeto de error para ver si algo salió mal y puedes manejarlo. En caso de que no haya ningún error, puedes utilizar los argumentos posteriores y seguir adelante.
fs.readFile('/text.txt', function(err, data) {
if (err) {
console.log(err);
} else {
console.log(data);
}
});
esta medio confuso esto, pero creo que es cuestión de ponerlo en práctica!
los throw no funcionan con callbacks asincronos
Información complementaria: https://nodejs.org/api/errors.html#errors_error_first_callbacks
¿por qué no seguir el modelo de una promesa resolve/reject?
Siempreee el error es lo primero que se evalua
function asincrona() {
setTimeout(function () {
try {
let a =3+z;
callback(null,a);
} catch (error) {
callback(error);
}
},1000);
}
asincrona(function (error,dato) {
if(error){
console.error('tenemos un error');
console.error(error);
return false;
}
console.log('todo ha ido bien',data);
})```
Con el pensamiento de que todo en algún momento puede fallar, una convención que se ha generado es poner como primer parámetro el error en todos los módulos que vaya a generar.
function asyncFunction(callback) {
setTimeout(() => {
try {
let a = 3 + z
callback(null, a)
} catch (e) {
callback(e, null)
}
}, 1000)
}
En este momento hay una función asíncrona, que tiene como parámetro un Callback, y esta generando un error debido a que la variable z
no esta definida. Para agarrar el error se puede hacer el Error First Callback.
asyncFunction((err, data) => {
if (err) {
console.error('Tenemos un error')
console.error(err)
return false
}
console.log(`Todo va bien, la data es ${data}`)
})
El primer parámetro que recibe el Callback es el error para seguir la convención que se utiliza últimamente.
Este patrón se debe seguir cuando se trabaje con funciones asíncronas.
En este caso lanzar un error mediante throw
no va a funcionar debido a que se esta manejando funciones asíncronas y estás son manejadas por el Callback Queue y el Event Loop.
try catch no es util para las funciones asincronas porque no captura el error, ya que esta en otro hilo
Ey como estan? retoque un poquitin el codigo para que sea mas entendible como funciona los callbacks en este caso…
function asincrona(callback) {
setTimeout(function() {
try{
let dato = 3 + z;
callback(null,dato);
} catch(err) {
callback(err);
}
}, 1000);
}
//esta seria la funcion callback
asincrona(function (err, dato) {
if(err) {
console.error(err.message);
return false;
}
console.log("todo ha ido bien " + dato);
})
Con esto se puede ver como el parametro de “asincrona”, empieza a trabajar como llamada a una funcion nueva. Esta genera que segun como funcione el codigo, si no genera error enonces llamo a la funcion callback y le paso como parametro dato, pero si falla entonces llamo a callback y le paso como parametro err.
Los Error First Callbacks se utilizan para pasar primero el error y los datos posteriormente. Entonces, puedes verificar el primer argumento, es decir, el objeto de error para ver si algo salió mal y puedes manejarlo.
function asincrona(callback) {
setTimeout(function() {
try {
let a = 3 + z;
callback(null, a)
} catch (error) {
callback(error);
}
}, 1000)
}
asincrona(function(err, dato) {
if (err) {
console.error('Tenemos un error');
console.error(err);
//throw err; // No va a funcionar cuando es asincrona
return false;
}
console.log('Todo ha ido bien, el dato es', dato)
})
Pregunta de examen:
En un callback, ¿cuál debería ser el primer parámetro?
Error First Callback. Cuando utilizamos un callback, debemos tener en cuenta que todo puede fallar, por lo que el primer parámetro que definamos debe ser el de error.
Hola! Si alguien tiene dudas de cómo lidiar con errores en Js y sabe un poco de english jaja, mire este articulo de como lidiar con errores asyncronos
/* Siempre que tengamos un callback el primer parametro deberia ser el error por que es una convension pensando en que todo puede fallar y debemos ser capaces de controlarlo */
/* throw error para funciones asincronas no va a funcionar */
function asincrona(callback) {
setTimeout(function() {
try {
let a = 3 + z;
callback(null, a);
} catch (e) {
callback(e);
}
}, 1000)
}
asincrona(function (err, dato) {
if (err) {
console.error('Tenemos un error');
console.error(err);
return false;
}
console.log('todo ha ido bien, mi data es', dato);
})
😃 El Error First Callbacks: Se utilizan para pasar primero el error y los datos posteriormente. Podemos verificar el primer argumento. El objeto de error para ver si algo salió mal para poder manejarlo. En caso de que no haya ningún error, podemos utilizar los argumentos y seguir adelante.
function asincrona(callBack) {
setTimeout(function() {
try {
let a = 3 + z;
callBack(null, a);
} catch (e) {
callBack(e);
}
}, 1000);
}
asincrona(function(err, dato) {
if (err) {
console.error("Tenemos un error");
console.error(err);
// Para funciones sincronas --> throw err
return false;
}
console.log("Todo ha ido bien, mi data es", dato);
});
Error First Callback
Un patrón, siempre que tengamos un callback el primer parámetro debería ser el error.
Para funciones síncronas
throw err;
/* Función para mí callback */
function mycb(err, dato){
if (err){
/* Capturar el error */
console.error("Ha ocurrido un error")
console.error(err)
return false; /* Buena práctica para detener la ejecución de la función */
} else{
console.log("Todo bien" + dato);
}
}
/* Función principal asíncrona */
function setError(callback) {
setTimeout(() => {
try {
let a = 3 + Z;
/* mycb(null, a) */
callback(null, a);
} catch (e) {
/* mycb(e, null) */
callback(e);
}
}, 3000);
}
/* Llamado */
setError(mycb);
GO se parece mucho a JS en el sentido de err first.
function Asyncro(callback){
setTimeout(function() {
try{
let a = 3 + Zesz;
callback(null, a);
} catch(e){
callback(e);
}
})
}
Asyncro(function(err, date) {
if(err){
console.error('we have a error');
console.error(err)
// throw err; //No funciona en async
}
})
No sabia que mandar primero el error era una convención, simplemente creí que era una buena practica. Aunque considero que lo realmente importante es siempre contemplar que algo pude fallar. El uso del Try / Catch es escencial
/*
ErrorFirst
*/
function asincrona(callback){
setTimeout(() => {
try {
let a = 3 + z;
callback(null, a);
} catch(error) {
callback(error);
}
}, 1000);
}
/*
Con errorFirst, no funciona el throw, este es mejor
usarlo en funciones sincronas
*/
asincrona(function(error, dato){
if(error) {
console.error('Tenemos un error', error.message);
// throw error;
return false;
};
console.log('Todo ha ido bien', dato);
})```
interesante,. el manejo de errores
function asincrona(callback) {
setTimeout(() => {
try {
let a = 3 + z;
callback(null, a);
} catch (error) {
callback(error);
}
}, 1000);
};
asincrona( (error, dato) => {
if (error) {
console.error('tenermos error');
console.error(error);
return false;
//no funciona con funciones asicronas
//throw error;
}
console.log('todo bien', dato);
})
Aquí el código con apuntes.
function asincrona(callback) {
setTimeout(function () {
try {
let a = 3 + z;
callback(null, a);
} catch (e) {
callback(e);
}
}, 1000);
}
// !PATRON ERRORFIST,CALLBACK ES EL QUE TENEMOS QUE SEGUIR SIEMPRE QUE TRABAJEMOS CON FUNCIONES ASINCRONAS Y CALLBACKS
asincrona(function (err, data) {
if (err) {
console.error('Tenemos un error');
console.error(err);
return false;
//throw err // !EL PATRON THROW VA A VENIR MUY BIEN PARA FUNCIONES SINCRONAS PERO NO VA A FUNCIONAR EN ASINCRONÍA
}
console.log('Todo ha ido bien mi data es', data);
});
Tambien podemos usar el operador ternario de la siguiente manera para que quede mas bonito y legible:
fs.readFile('/text.txt', (err, data) => {
(err) ? console.error('Hubo un error', err.message) : console.log('Todo ok, tu info es:', data)
}
function asincrona() {
setTimeout(function () {
try {
let a =3+z;
callback(null,a);
} catch (error) {
callback(error);
}
},1000);
}
asincrona(function (error,dato) {
if(error){
console.error('tenemos un error');
console.error(error);
return false;
}
console.log('todo ha ido bien',data);
})
**veo que la mayoria omite el hecho de leer los erros de consola detenidamente, hay un error del tipo referenceError que se debe a que en la suma no se ha declarado el valor de “z” **
z is not defined --> ojo a esta observacion
No me quedo muy claro “Error First Callbacks”. Algún aporte al respecto, please
Aquí hay un pequeño error, el hecho de que no funcione el throw error
no es porque la función sea asincrona, sino porque estamos usando callbacks y en el momento en que se lanza el throw error
, el contexto que le llamó :
...
} catch (error) {
callback(error);
}
....
Ya no existe, hay que recordar que los errores se elevan, por lo que el error sucedió dentro de la funcion “callback” que en este caso es la funcion llamada “asincrona” , por ejemplo, si ejecutan esto van a ver como es que el error se eleva y si que se puede seguir manejando :
function asincrona(callback) {
setTimeout(function() {
try {
let a = 3 + z;
callback(null, a)
} catch (error) {
try{
callback(error);
}catch(e){
console.log('aqui va a venir despues del throw err')
}
}
}, 1000)
}
Por todo esto, el que no funcione el throw error
no tiene nada que ver con que sea asincrona, sino con que estemos usando callbacks
, las promesas tambíen son asíncronas y si las manejamos bien podemos usar throws sin problemas en ambos casos.
Error-First Callback en Node.js es una función que devuelve un objeto de error o cualquier dato exitoso devuelto por la función.
Todo puede fallar, importante tenerlo siempre en cuenta.
super 😃
Wow 🤯
Very useful!
Bastante util!
Cool
en lo personal si existe dicho metodo a sincrono, con promesas prefiero usarlo de esa manera o adaptarlo ya que callbacks es una forma de programar algo arcaica, aunque no quiere decir que no los use, pero que ellos sean el core de lo que hago no es mi objetivo
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?