3 ms·
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
by m1el 9y ago
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.
- nailer 9y 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?
- m1el 9y 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.
- nailer 9y agoThanks for replying. > Requiring an exception to preserve the scope in some specific case is... problematic, to say the least. I was thinking about having exceptions preserve scope in all cases, or in all cases if a flag is turned on. I don't quite understand what the difference is between `catch(error)` when using await/promises and `catch(error)` when doing something else. Is the main concern here the overhead?