Jul 31, 2020 · Jul 29, 2020 · Jul 29, 2020 · Jul 29, 2020 · Jul 29, 2020 · Jul 29, 2020
diff --git a/1-js/11-async/04-promise-error-handling/01-error-async/solution.md b/1-js/11-async/04-promise-error-handling/01-error-async/solution.md
 The answer is: **no,it won't**:
 La respuesta es: **no,no lo hará**:

 ```js run
 new Promise(function(resolve, reject) {
 }).catch(alert);
 ```

 As said in the chapter, there's an "implicit`try..catch`" around the function code. So all synchronous errors are handled.
 Como vimos en el capítulo, hay un "`try..catch` implícito" en el código de la función. Así se manejan todos los errores síncronos.

 But here the erroris generated not while the executor is running, but later. So the promise can't handle it.
 Pero aquí el errorno se genera mientras el ejecutor está corriendo, sino más tarde. Entonces la promesa no puede manejarlo.
diff --git a/1-js/11-async/04-promise-error-handling/01-error-async/task.md b/1-js/11-async/04-promise-error-handling/01-error-async/task.md
 # Errorin setTimeout
 # Erroren setTimeout

 What do you think? Will the`.catch` trigger? Explain your answer.
 ¿Qué crees que pasará? ¿Se disparará el`.catch`? Explica tu respuesta.

 ```js
 new Promise(function(resolve, reject) {
diff --git a/1-js/11-async/04-promise-error-handling/article.md b/1-js/11-async/04-promise-error-handling/article.md

 #Error handling with promises
 #Manejo de errores con promesas

 Promise chains are great at error handling. When a promise rejects, the controljumps to the closest rejection handler. That's very convenient in practice.
 Las promesas encadenadas son excelentes manejando los errores. Cuando una promesa es rechazada, el controlsalta al manejador de rechazos más cercano. Esto es muy conveniente en la práctica.

 For instance, in the code below theURLto`fetch`is wrong (nosuch site) and`.catch`handles the error:
 Por ejemplo, en el código de abajo, laURLa la cual se le hace`fetch`es incorrecta (noexiste el sitio) y al ser rechazada`.catch`maneja el error:

 ```js run
 *!*
 fetch('https://no-such-server.blabla') //rejects
 fetch('https://no-such-server.blabla') //Promesa rechazada
 */!*
  .then(response => response.json())
  .catch(err => alert(err)) // TypeError: failed to fetch (the text may vary)
  .catch(err => alert(err)) // TypeError: failed to fetch (El texto puede variar, dependiendo del error)
 ```

 As you can see, the `.catch`doesn't have to be immediate. It may appear after one or maybe several `.then`.
 Como puedes ver, el `.catch`no tiene que escribirse inmediatamente después de la promesa. Este puede aparecer después de uno o quizás varios `.then`.

 Or, maybe, everything is all right with the site, but the response is not valid JSON. The easiest way to catch all errors is to append`.catch`to the end of chain:
 O, puede ocurrir, que todo en el sitio se encuentre bien, pero la respuesta no es un JSON válido. La forma más fácil de detectar todos los errores es agregando`.catch`al final de la cadena de promesas:

 ```js run
 fetch('/article/promise-chaining/user.json')
 */!*
 ```

 Normally, such`.catch`doesn't trigger at all. But if any of the promises above rejects (a network problem or invalid jsonorwhatever),then it would catch it.
 Lo normal es que tal`.catch`no se dispare en absoluto. Pero si alguna de las promesas anteriores es rechazada (por un error de red, un JSON inválidoorcualquier otra razón),entonces el error es capturado.

 ##Implicittry..catch
 ## try..catch implícito

 The code of a promise executor and promise handlers has an "invisible `try..catch`" around it. If an exception happens, it gets caught and treated as a rejection.
 El código de un ejecutor de promesas y de manejadores de promesas tiene embebido un " `try..catch` invisible". Si ocurre una excepción, esta es atrapada y es tratada como un rechazo.

 For instance, this code:
 Por ejemplo, este código:

 ```js run
 new Promise((resolve, reject) => {
 }).catch(alert); // Error: Whoops!
 ```

 ...Works exactly the same as this:
 ...Hace exactamente lo mismo que este:

 ```js run
 new Promise((resolve, reject) => {
 }).catch(alert); // Error: Whoops!
 ```

 The "invisible`try..catch`" around the executor automatically catches theerrorand turns it into rejected promise.
 El "`try..catch` invisible" embebido en el ejecutor detecta automáticamente elerrory lo convierte en una promesa rechazada.

 This happens not only in the executor function, but in its handlers as well. If we `throw`insidea `.then` handler, that means a rejected promise, so thecontroljumps to the nearest error handler.
 Esto sucede no solo en la función ejecutora, sino también en sus manejadores. Si hacemos `throw`dentro de una llamadaa `.then`, esto devolverá una promesa rechazada, por lo que elcontrolsalta al manejador de errores más cercano.

 Here's an example:
 Por ejemplo:

 ```js run
 new Promise((resolve, reject) => {
  resolve("ok");
 }).then((result) => {
 *!*
  throw new Error("Whoops!"); //rejects the promise
  throw new Error("Whoops!"); //rechaza la promesa
 */!*
 }).catch(alert); // Error: Whoops!
 ```

 This happens for all errors, not just those caused by the`throw` statement. For example, a programmingerror:
 Esto sucede con todos los errores, no solo los causados por la sentencia de excepción`throw`. Por ejemplo, unerror de programación:

 ```js run
 new Promise((resolve, reject) => {
  resolve("ok");
 }).then((result) => {
 *!*
  blabla(); //no such function
  blabla(); //Función inexistente
 */!*
 }).catch(alert); // ReferenceError: blabla is not defined
 ```

 The final`.catch`not only catches explicit rejections, but also accidental errors in the handlers above.
 El`.catch`del final no solo detecta rechazos explícitos, sino también los errores accidentales en los manejadores anteriores.

 ## Rethrowing
 ## Rethrowing (relanzamiento de errores)

 As we already noticed,`.catch`at the end of the chain issimilarto `try..catch`.We may have as many`.then`handlers as we want, and then use a single `.catch`at the end to handle errors in all of them.
 Como ya vimos, el`.catch`del final essimilara `try..catch`.Podemos tener tantos manejadores`.then`como queramos, y luego usar un solo `.catch`al final para manejar los errores en todos ellos.

 In a regular`try..catch`we can analyze the errorand maybe rethrow it if it can't be handled. The same thing is possible for promises.
 En un`try..catch`normal, podemos analizar el errory quizá volver a lanzarlo si no se puede manejar. Lo mismo podemos hacer con las promesas.

 If we `throw`inside`.catch`,then thecontrolgoes to the next closest error handler. And if we handle theerrorand finish normally, then it continues to the next closest successful`.then`handler.
 Si hacemos `throw`dentro de`.catch`,elcontrolpasa a otro manejador de errores más cercano. Y, si manejamos elerrory terminamos de forma correcta, entonces se continúa con el siguiente manejador`.then`existoso.

 In the example below the`.catch`successfully handles theerror:
 En el ejemplo de abajo, el`.catch`maneja elerror de forma exitosa:

 ```js run
 //the execution: catch -> then
 //Ejecución: catch -> then
 new Promise((resolve, reject) => {

  throw new Error("Whoops!");

 }).catch(function(error) {

  alert("The error is handled, continue normally");
  alert("Error manejado, se continuará con la ejecución del código");

 }).then(() => alert("Next successful handler runs"));
 }).then(() => alert("El siguiente manejador exitoso se ejecuta"));
 ```

 Here the `.catch`block finishes normally. So the next successful`.then` handler is called.
 Aqui el `.catch`termina de forma correcta. Entonces se ejecuta el siguiente manejador exitoso`.then`.

 In the example below we see the other situation with`.catch`.The handler `(*)`catches the errorand just can't handle it (e.g. it only knows how to handle`URIError`),so it throws it again:
 En el siguiente ejemplo podemos ver otra situación con`.catch`.El manejador `(*)`detecta el errory simplemente no puede manejarlo (en el ejemplo solo sabe que hacer con un`URIError`),por lo que lo lanza nuevamente:

 ```js run
 //the execution: catch -> catch
 //Ejecución: catch -> catch
 new Promise((resolve, reject) => {

  throw new Error("Whoops!");

 }).catch(function(error) { // (*)

  if (error instanceof URIError) {
    //handle it
    //Aqui se manejaría el error
  } else {
    alert("Can't handle such error");
    alert("No puedo manejar este error");

 *!*
    throw error; //throwing this or anothererrorjumps to the nextcatch
    throw error; //Lanza este error u otroerrorque salte en el siguientecatch.
 */!*
  }

 }).then(function() {
  /*doesn't run here */
  /*Esto no se ejecuta */
 }).catch(error => { // (**)

  alert(`The unknown errorhas occurred: ${error}`);
  //don't return anything=>execution goes the normal way
  alert(`Ocurrió un errordesconocido: ${error}`);
  //No se devuelve nada=>La ejecución continúa de forma normal

 });
 ```

 The execution jumps from the first`.catch` `(*)`to the next one`(**)`down the chain.
 La ejecución salta del primer`.catch` `(*)`al siguiente`(**)`en la cadena.

 ##Unhandled rejections
 ##Rechazos no manejados

 What happens when an erroris not handled? For instance, we forgot to append`.catch`to the end of the chain, like here:
 ¿Que sucede cuanto un errorno es manejado? Por ejemplo, si olvidamos agregar`.catch`al final de una cadena de promesas, como aquí:

 ```js untrusted run refresh
 new Promise(function() {
  noSuchFunction(); //Error here(nosuch function)
  noSuchFunction(); //Aquí hay un error(noexiste la función)
 })
  .then(() => {
    //successful promise handlers, one or more
  }); //without .catchat the end!
    //manejador de una o más promesas existosas
  }); //sin .catchal final!
 ```

 In case of anerror,the promise becomes rejected, and the execution should jump to the closest rejection handler. But there is none. So the errorgets "stuck". There'snocode to handle it.
 En caso de que se genere unerror,la promesa se rechaza y la ejecución salta al manejador de rechazos más cercano. Pero aquí no hay ninguno. Entonces el errorse "atasca", ya quenohay código para manejarlo.

 In practice, just like with regular unhandled errors in code, it means that something has gone terribly wrong.
 En la práctica, al igual que con los errores comunes no manejados en el código, esto significa que algo ha salido terriblemente mal.

 What happens when a regular erroroccurs and is not caught by `try..catch`?The scriptdies with a message in the console. A similarthing happens with unhandled promise rejections.
 ¿Que sucede cuando ocurre un errorregular y no es detectado por `try..catch`?El scriptmuere con un mensaje en la consola. Algo similarsucede con los rechazos de promesas no manejadas.

 The JavaScript engine tracks such rejections and generates a global error in that case. You can see it in the console if you run the example above.
 En este caso, el motor de JavaScript rastrea el rechazo y lo envía al ámbito global. Puedes ver en consola el error generado si ejecutas el ejemplo anterior.

 In the browser we can catch such errors using the event `unhandledrejection`:
 En el navegador podemos detectar tales errores usando el evento `unhandledrejection`:

 ```js run
 *!*
 window.addEventListener('unhandledrejection', function(event) {
  //theeventobject has two special properties:
  alert(event.promise); // [object Promise] -the promise that generated the error
  alert(event.reason); // Error: Whoops! -the unhandled error object
  //el objetoeventtiene dos propiedades especiales:
  alert(event.promise); // [objeto Promesa] -La promesa que fue rechazada
  alert(event.reason); // Error: Whoops! -Motivo por el cual se rechaza la promesa
 });
 */!*

 new Promise(function() {
  throw new Error("Whoops!");
 }); //nocatchto handle the error
 }); //No hay un .catchfinal para manejar el error
 ```

 The event is the part of the [HTMLstandard](https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections).
 Este evento es parte del [standard HTML](https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections).

 If an error occurs, and there'sno `.catch`,the`unhandledrejection` handler triggers, and gets the `event`object with the information about the error,so we can do something.
 Si se produce un error, ynohay un`.catch`,se dispara`unhandledrejection`, y se obtiene el objeto `event`el cual contiene información sobre el error,por lo que podemos hacer algo con el error (manejar el error).

 Usually such errors are unrecoverable, so our best way out is to inform the user about the problem and probably report the incident to the server.
 Usualmente estos errores no son recuperables, por lo que la mejor salida es informar al usuario sobre el problema y probablemente reportar el incidente al servidor.

 In non-browser environments likeNode.jsthere are other ways to track unhandled errors.
 En entornos fuera del navegador comoNode.jsexisten otras formas de rastrear errores no manejados.

 ##Summary
 ##Resumen

 - `.catch`handles errors in promises of all kinds: be it a `reject()` call, or an errorthrown in a handler.
 -We should place`.catch`exactly in places where we want to handle errors and know how to handle them. The handler should analyze errors (custom error classes help) and rethrow unknown ones (maybe they are programming mistakes).
 -It's ok not to use `.catch` at all, if there'snoway to recover from an error.
 -In any case we should have the `unhandledrejection`event handler (for browsers, and analogs for other environments) to track unhandled errors and inform the user (and probably our server) about them, so that our app never "just dies".
 - `.catch`maneja errores de todo tipo: ya sea una llamada a `reject()`, o un errorque arroja un manejador.
 -Debemos colocar`.catch`exáctamente en los lugares donde queremos manejar los errores y saber como manejarlos. El manejador analiza los errores (los errores personalizados) y, (en caso de no conocerse la razón del error) se lanzan los errores desconocidos (tal vez sean errores de programación).
 -Está bien no usar siempre `.catch`, sinohay forma de recuperarse de un error.
 -En cualquier caso, deberíamos tener el evento `unhandledrejection`(para navegadores, o el equivalente en otros entornos) para rastrear errores no manejados e informar al usuario (y probablemente al servidor) para que nuestra aplicación nunca "simplemente muera".
diff --git a/1-js/11-async/04-promise-error-handling/getMessage.js b/1-js/11-async/04-promise-error-handling/getMessage.js
 function getMessage() {
  return "Hello, world!";
  return "Hola, Mundo!";
 }
Original file line number	Diff line number	Diff line change
		@@ -1,4 +1,4 @@
		The answer is: no,it won't:
		La respuesta es: no,no lo hará:

		```js run
		new Promise(function(resolve, reject) {
Expand All		@@ -8,6 +8,6 @@ new Promise(function(resolve, reject) {
		}).catch(alert);
		```

		As said in the chapter, there's an "implicit`try..catch`" around the function code. So all synchronous errors are handled.
		Como vimos en el capítulo, hay un "`try..catch` implícito" en el código de la función. Así se manejan todos los errores síncronos.

		But here the erroris generated not while the executor is running, but later. So the promise can't handle it.
		Pero aquí el errorno se genera mientras el ejecutor está corriendo, sino más tarde. Entonces la promesa no puede manejarlo.
Original file line number	Diff line number	Diff line change
		@@ -1,6 +1,6 @@
		# Errorin setTimeout
		# Erroren setTimeout

		What do you think? Will the`.catch` trigger? Explain your answer.
		¿Qué crees que pasará? ¿Se disparará el`.catch`? Explica tu respuesta.

		```js
		new Promise(function(resolve, reject) {
Expand Down
Original file line number	Diff line number	Diff line change
		@@ -1,21 +1,21 @@

		#Error handling with promises
		#Manejo de errores con promesas

		Promise chains are great at error handling. When a promise rejects, the controljumps to the closest rejection handler. That's very convenient in practice.
		Las promesas encadenadas son excelentes manejando los errores. Cuando una promesa es rechazada, el controlsalta al manejador de rechazos más cercano. Esto es muy conveniente en la práctica.

		For instance, in the code below theURLto`fetch`is wrong (nosuch site) and`.catch`handles the error:
		Por ejemplo, en el código de abajo, laURLa la cual se le hace`fetch`es incorrecta (noexiste el sitio) y al ser rechazada`.catch`maneja el error:

		```js run
		!
		fetch('https://no-such-server.blabla') //rejects
		fetch('https://no-such-server.blabla') //Promesa rechazada
		/!
		.then(response => response.json())
		.catch(err => alert(err)) // TypeError: failed to fetch (the text may vary)
		.catch(err => alert(err)) // TypeError: failed to fetch (El texto puede variar, dependiendo del error)
		```

		As you can see, the `.catch`doesn't have to be immediate. It may appear after one or maybe several `.then`.
		Como puedes ver, el `.catch`no tiene que escribirse inmediatamente después de la promesa. Este puede aparecer después de uno o quizás varios `.then`.

		Or, maybe, everything is all right with the site, but the response is not valid JSON. The easiest way to catch all errors is to append`.catch`to the end of chain:
		O, puede ocurrir, que todo en el sitio se encuentre bien, pero la respuesta no es un JSON válido. La forma más fácil de detectar todos los errores es agregando`.catch`al final de la cadena de promesas:

		```js run
		fetch('/article/promise-chaining/user.json')
Expand All		@@ -38,13 +38,13 @@ fetch('/article/promise-chaining/user.json')
		/!
		```

		Normally, such`.catch`doesn't trigger at all. But if any of the promises above rejects (a network problem or invalid jsonorwhatever),then it would catch it.
		Lo normal es que tal`.catch`no se dispare en absoluto. Pero si alguna de las promesas anteriores es rechazada (por un error de red, un JSON inválidoorcualquier otra razón),entonces el error es capturado.

		##Implicittry..catch
		## try..catch implícito

		The code of a promise executor and promise handlers has an "invisible `try..catch`" around it. If an exception happens, it gets caught and treated as a rejection.
		El código de un ejecutor de promesas y de manejadores de promesas tiene embebido un " `try..catch` invisible". Si ocurre una excepción, esta es atrapada y es tratada como un rechazo.

		For instance, this code:
		Por ejemplo, este código:

		```js run
		new Promise((resolve, reject) => {
Expand All		@@ -54,7 +54,7 @@ new Promise((resolve, reject) => {
		}).catch(alert); // Error: Whoops!
		```

		...Works exactly the same as this:
		...Hace exactamente lo mismo que este:

		```js run
		new Promise((resolve, reject) => {
Expand All		@@ -64,141 +64,141 @@ new Promise((resolve, reject) => {
		}).catch(alert); // Error: Whoops!
		```

		The "invisible`try..catch`" around the executor automatically catches theerrorand turns it into rejected promise.
		El "`try..catch` invisible" embebido en el ejecutor detecta automáticamente elerrory lo convierte en una promesa rechazada.

		This happens not only in the executor function, but in its handlers as well. If we `throw`insidea `.then` handler, that means a rejected promise, so thecontroljumps to the nearest error handler.
		Esto sucede no solo en la función ejecutora, sino también en sus manejadores. Si hacemos `throw`dentro de una llamadaa `.then`, esto devolverá una promesa rechazada, por lo que elcontrolsalta al manejador de errores más cercano.

		Here's an example:
		Por ejemplo:

		```js run
		new Promise((resolve, reject) => {
		resolve("ok");
		}).then((result) => {
		!
		throw new Error("Whoops!"); //rejects the promise
		throw new Error("Whoops!"); //rechaza la promesa
		/!
		}).catch(alert); // Error: Whoops!
		```

		This happens for all errors, not just those caused by the`throw` statement. For example, a programmingerror:
		Esto sucede con todos los errores, no solo los causados por la sentencia de excepción`throw`. Por ejemplo, unerror de programación:

		```js run
		new Promise((resolve, reject) => {
		resolve("ok");
		}).then((result) => {
		!
		blabla(); //no such function
		blabla(); //Función inexistente
		/!
		}).catch(alert); // ReferenceError: blabla is not defined
		```

		The final`.catch`not only catches explicit rejections, but also accidental errors in the handlers above.
		El`.catch`del final no solo detecta rechazos explícitos, sino también los errores accidentales en los manejadores anteriores.

		## Rethrowing
		## Rethrowing (relanzamiento de errores)

		As we already noticed,`.catch`at the end of the chain issimilarto `try..catch`.We may have as many`.then`handlers as we want, and then use a single `.catch`at the end to handle errors in all of them.
		Como ya vimos, el`.catch`del final essimilara `try..catch`.Podemos tener tantos manejadores`.then`como queramos, y luego usar un solo `.catch`al final para manejar los errores en todos ellos.

		In a regular`try..catch`we can analyze the errorand maybe rethrow it if it can't be handled. The same thing is possible for promises.
		En un`try..catch`normal, podemos analizar el errory quizá volver a lanzarlo si no se puede manejar. Lo mismo podemos hacer con las promesas.

		If we `throw`inside`.catch`,then thecontrolgoes to the next closest error handler. And if we handle theerrorand finish normally, then it continues to the next closest successful`.then`handler.
		Si hacemos `throw`dentro de`.catch`,elcontrolpasa a otro manejador de errores más cercano. Y, si manejamos elerrory terminamos de forma correcta, entonces se continúa con el siguiente manejador`.then`existoso.

		In the example below the`.catch`successfully handles theerror:
		En el ejemplo de abajo, el`.catch`maneja elerror de forma exitosa:

		```js run
		//the execution: catch -> then
		//Ejecución: catch -> then
		new Promise((resolve, reject) => {

		throw new Error("Whoops!");

		}).catch(function(error) {

		alert("The error is handled, continue normally");
		alert("Error manejado, se continuará con la ejecución del código");

		}).then(() => alert("Next successful handler runs"));
		}).then(() => alert("El siguiente manejador exitoso se ejecuta"));
		```

		Here the `.catch`block finishes normally. So the next successful`.then` handler is called.
		Aqui el `.catch`termina de forma correcta. Entonces se ejecuta el siguiente manejador exitoso`.then`.

		In the example below we see the other situation with`.catch`.The handler `(*)`catches the errorand just can't handle it (e.g. it only knows how to handle`URIError`),so it throws it again:
		En el siguiente ejemplo podemos ver otra situación con`.catch`.El manejador `(*)`detecta el errory simplemente no puede manejarlo (en el ejemplo solo sabe que hacer con un`URIError`),por lo que lo lanza nuevamente:

		```js run
		//the execution: catch -> catch
		//Ejecución: catch -> catch
		new Promise((resolve, reject) => {

		throw new Error("Whoops!");

		}).catch(function(error) { // (*)

		if (error instanceof URIError) {
		//handle it
		//Aqui se manejaría el error
		} else {
		alert("Can't handle such error");
		alert("No puedo manejar este error");

		!
		throw error; //throwing this or anothererrorjumps to the nextcatch
		throw error; //Lanza este error u otroerrorque salte en el siguientecatch.
		/!
		}

		}).then(function() {
		/doesn't run here /
		/Esto no se ejecuta /
		}).catch(error => { // (**)

		alert(`The unknown errorhas occurred: ${error}`);
		//don't return anything=>execution goes the normal way
		alert(`Ocurrió un errordesconocido: ${error}`);
		//No se devuelve nada=>La ejecución continúa de forma normal

		});
		```

		The execution jumps from the first`.catch` `()`to the next one`(*)`down the chain.
		La ejecución salta del primer`.catch` `()`al siguiente`(*)`en la cadena.

		##Unhandled rejections
		##Rechazos no manejados

		What happens when an erroris not handled? For instance, we forgot to append`.catch`to the end of the chain, like here:
		¿Que sucede cuanto un errorno es manejado? Por ejemplo, si olvidamos agregar`.catch`al final de una cadena de promesas, como aquí:

		```js untrusted run refresh
		new Promise(function() {
		noSuchFunction(); //Error here(nosuch function)
		noSuchFunction(); //Aquí hay un error(noexiste la función)
		})
		.then(() => {
		//successful promise handlers, one or more
		}); //without .catchat the end!
		//manejador de una o más promesas existosas
		}); //sin .catchal final!
		```

		In case of anerror,the promise becomes rejected, and the execution should jump to the closest rejection handler. But there is none. So the errorgets "stuck". There'snocode to handle it.
		En caso de que se genere unerror,la promesa se rechaza y la ejecución salta al manejador de rechazos más cercano. Pero aquí no hay ninguno. Entonces el errorse "atasca", ya quenohay código para manejarlo.

		In practice, just like with regular unhandled errors in code, it means that something has gone terribly wrong.
		En la práctica, al igual que con los errores comunes no manejados en el código, esto significa que algo ha salido terriblemente mal.

		What happens when a regular erroroccurs and is not caught by `try..catch`?The scriptdies with a message in the console. A similarthing happens with unhandled promise rejections.
		¿Que sucede cuando ocurre un errorregular y no es detectado por `try..catch`?El scriptmuere con un mensaje en la consola. Algo similarsucede con los rechazos de promesas no manejadas.

		The JavaScript engine tracks such rejections and generates a global error in that case. You can see it in the console if you run the example above.
		En este caso, el motor de JavaScript rastrea el rechazo y lo envía al ámbito global. Puedes ver en consola el error generado si ejecutas el ejemplo anterior.

		In the browser we can catch such errors using the event `unhandledrejection`:
		En el navegador podemos detectar tales errores usando el evento `unhandledrejection`:

		```js run
		!
		window.addEventListener('unhandledrejection', function(event) {
		//theeventobject has two special properties:
		alert(event.promise); // [object Promise] -the promise that generated the error
		alert(event.reason); // Error: Whoops! -the unhandled error object
		//el objetoeventtiene dos propiedades especiales:
		alert(event.promise); // [objeto Promesa] -La promesa que fue rechazada
		alert(event.reason); // Error: Whoops! -Motivo por el cual se rechaza la promesa
		});
		/!

		new Promise(function() {
		throw new Error("Whoops!");
		}); //nocatchto handle the error
		}); //No hay un .catchfinal para manejar el error
		```

		The event is the part of the [HTMLstandard](https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections).
		Este evento es parte del [standard HTML](https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections).

		If an error occurs, and there'sno `.catch`,the`unhandledrejection` handler triggers, and gets the `event`object with the information about the error,so we can do something.
		Si se produce un error, ynohay un`.catch`,se dispara`unhandledrejection`, y se obtiene el objeto `event`el cual contiene información sobre el error,por lo que podemos hacer algo con el error (manejar el error).

		Usually such errors are unrecoverable, so our best way out is to inform the user about the problem and probably report the incident to the server.
		Usualmente estos errores no son recuperables, por lo que la mejor salida es informar al usuario sobre el problema y probablemente reportar el incidente al servidor.

		In non-browser environments likeNode.jsthere are other ways to track unhandled errors.
		En entornos fuera del navegador comoNode.jsexisten otras formas de rastrear errores no manejados.

		##Summary
		##Resumen

		- `.catch`handles errors in promises of all kinds: be it a `reject()` call, or an errorthrown in a handler.
		-We should place`.catch`exactly in places where we want to handle errors and know how to handle them. The handler should analyze errors (custom error classes help) and rethrow unknown ones (maybe they are programming mistakes).
		-It's ok not to use `.catch` at all, if there'snoway to recover from an error.
		-In any case we should have the `unhandledrejection`event handler (for browsers, and analogs for other environments) to track unhandled errors and inform the user (and probably our server) about them, so that our app never "just dies".
		- `.catch`maneja errores de todo tipo: ya sea una llamada a `reject()`, o un errorque arroja un manejador.
		-Debemos colocar`.catch`exáctamente en los lugares donde queremos manejar los errores y saber como manejarlos. El manejador analiza los errores (los errores personalizados) y, (en caso de no conocerse la razón del error) se lanzan los errores desconocidos (tal vez sean errores de programación).
		-Está bien no usar siempre `.catch`, sinohay forma de recuperarse de un error.
		-En cualquier caso, deberíamos tener el evento `unhandledrejection`(para navegadores, o el equivalente en otros entornos) para rastrear errores no manejados e informar al usuario (y probablemente al servidor) para que nuestra aplicación nunca "simplemente muera".
Original file line number	Diff line number	Diff line change
		@@ -1,3 +1,3 @@
		function getMessage() {
		return "Hello, world!";
		return "Hola, Mundo!";
		}