You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@Damaged-Organic In the future, please create new issues for new issues, rather than posting your new problem as a comment on an old issue. Otherwise, it's far more likely (in some cases, nearly guaranteed) that your problem will be overlooked, and even if it isn't, the solution will not be searchable by future users, and it will likely spam a bunch of other people who can't help you anyway.
AHD intentionally does not trigger the Domain error handler if you have a process.on('uncaughtException') handler, because it's only intended to handle cases that would crash the process. If you have your own handler that handles the error, then the error won't crash the process, so the domain should not trigger.
Sure. Thanks for your response. The issue I've mentioned might be unique for some use cases, but if it's a deliberate design choice, can you please explain why AHD supposed to work only in the case when there's no uncaughtException / unhandledRejection listeners already set (an error won't crash the process as you've mentioned)?
In my particular use case, I need to observe separate components of the application for errors. At the top level error handler, it is required to decide what to do with the component based on errors it might throw.
I understand that it is possible to do new Domain(...) at the application entry point to be that "root error handler", but I can't substitute regular processuncaughtException / unhandledRejection events with AHD if I don't have an access to the application root.
If anyone is constrained by some existing code and cannot change it, it becomes impossible to use this (AFAIK, the only decent substitute of the deprecated domain, which actually behaves as expected - throw on error becomes one of the process error events accordingly).
All I'm saying, would it really be a design/technical violation to include an additional behavior in the AHD API in form of the boolean flag which will keep Domains enabled even if the aforementioned process events are set, with error bubbling up accordingly?
The text was updated successfully, but these errors were encountered:
Originally posted by @isaacs in #23 (comment)
Sure. Thanks for your response. The issue I've mentioned might be unique for some use cases, but if it's a deliberate design choice, can you please explain why AHD supposed to work only in the case when there's no
uncaughtException
/unhandledRejection
listeners already set (an error won't crash the process as you've mentioned)?In my particular use case, I need to observe separate components of the application for errors. At the top level error handler, it is required to decide what to do with the component based on errors it might throw.
I understand that it is possible to do
new Domain(...)
at the application entry point to be that "root error handler", but I can't substitute regularprocess
uncaughtException
/unhandledRejection
events with AHD if I don't have an access to the application root.If anyone is constrained by some existing code and cannot change it, it becomes impossible to use this (AFAIK, the only decent substitute of the deprecated
domain
, which actually behaves as expected -throw
onerror
becomes one of the process error events accordingly).All I'm saying, would it really be a design/technical violation to include an additional behavior in the AHD API in form of the boolean flag which will keep Domains enabled even if the aforementioned process events are set, with error bubbling up accordingly?
The text was updated successfully, but these errors were encountered: