undefined | Better HN

0 pointsnailer8y ago0 comments

> No matter what you do, you can't access intermediateValue after you noticed the error..

Couldn't this be solved by dumping all values in the scope the exception was created? Ie this sounds like a VM feature request, rather than a limit of Promises.

0 comments

3 comments · 1 top-level

m1el8y ago· 2 in thread

This cannot be done the way you describe it.

We already have VM features to inspect the scope of a function that failed. The problem is, Promises "handle" the exception, and prevent users from using this feature.

I will repeat the statement: Promises catch exceptions thrown from handlers. This means that the scope in which the exception was thrown doesn't exist anymore.

nailerOP8y ago

[Small note: I'm trying to learn here, that's all]

I still don't understand. When a Promise throws an exception and we catch() it (assuming 'await' here as I've never used Promises with .then() for anything serious), couldn't the err passed to the catch() expose the necessary parts of the scope like it could for exceptions not created by Promises?

m1el8y ago

> couldn't the err passed to the catch() expose the necessary parts of the scope like it could for exceptions not created by Promises?

That would require Promises to create and use a new unique and intrusive API into the interpreter. Requiring an exception to preserve the scope in some specific case is... problematic, to say the least.

Instead exceptions in Promise callback could be handled as uncaught exceptions, which would solve the problem caused by Promises catching all exceptions and passing them as error values.

1 more reply

j / k navigate · click thread line to collapse