listening for each throw in the process

[tareksalem]

What is the problem this feature will solve?

Currently, we have process listeners to listen for uncaughtException, unhandledRejection, rejectionHandled to catch the unhandled errors in sync and async but we need another event to be emitted each time we have a throw or .reject statements in the process even if it is handled.

What is the feature you are proposing to solve the problem?

suppose we have a function that throws an error without a catch and this function is being called in another one that has caught, in this case, no event will be emitted however for logging purposes sometimes we need to log each error that happens in single-function one by one a

What alternatives have you considered?

No response

[mscdex]

This seems like something that should be handled in your code, not in node core. Alternatively you could write something that would transpile your code to automatically add such logging within catch scopes.

[tareksalem]

I think this is doable via a transpiler however nodejs is a runtime and targets to work with raw js without transpilers so supporting something like this would be better as nodejs has the management of the process not the transpiler.

what about if I created a PR regarding to this, do you thing it's a good idea?

[bnoordhuis]

No changes are required because you can already do it today through the Debugger.setPauseOnExceptions inspector command with { state: "all" }, then waiting for the Debugger.paused events to come in.

See https://nodejs.org/docs/latest/api/inspector.html for more details. I'll convert this to a discussion.

[tareksalem]

Thanks for your reply

Does this work for production?

I need to stream all the errors that happen in multiple code layers dynamically

[bnoordhuis]

Sure. There's a performance impact you'll need to evaluate but TANSTAAFL, of course.

[tareksalem]

why this is not implemented in process listener for better implementation?

[bnoordhuis]

I think what you're asking is "would performance be better if it was supported in some other way by node?" The answer is "probably not."