Es la misma razón que si tuvieras:

 const result = foo();

Entonces tendría una promesa almacenada en result y no el valor liquidado de la promesa.

Se inicia el código asíncrono, luego continúa la función de llamada.

Algún tiempo después , la promesa es rechazada, pero para entonces es demasiado tarde para que el código en test() la atrape.

Si hubiera await a ed foo() , lo que requeriría que test() sea async , entonces se detectaría.

De lo contrario, podría necesitar usar foo().catch(...) .

Las promesas son asincrónicas pero no estás esperando . Significa que el código continúa. Así que tienes que await o tienes que usar then().catch() . Algo como esto:

 function addTask(task) { setTimeout(() => { task.resolver() }, 1000) } function foo() { return new Promise((resolve, reject) => { const task = { resolver: function() { reject('task failed') } } addTask(task) }) } function test() { foo().then(console.log).catch(console.error); } // Uncaught (in promise) task failed test()

Para simplificar tu ejemplo:

 function foo() { return new Promise((resolve, reject) => setTimeout(reject, 1000)) } function test() { try { foo() } catch (e) { console.error("Error"); return; } console.log("OK!"); } test()

imprimirá "¡OK!" de hecho, haga que Node.js genere un UnhandledPromiseRejection, ya que la invocación de foo() es simplemente "tirar" el valor del resultado de la promesa. El catch() solo capturaría excepciones sincrónicas, no prometería rechazos.

Convertir la función en async function test() y await en foo() generará correctamente un Error y no un rechazo no controlado.