-
Notifications
You must be signed in to change notification settings - Fork 28.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reportException(ex) / reportError(ex) #38947
Comments
I don't understand what would be the semantics of that inside a Node.js process. What would that do? |
That's a good question and why I opened an issue. The two "obvious" options are:
|
Killing the process would basically be making a public "next tick" |
I guess the question here is, when would you, practically speaking, use this method over |
One difference is that calling this would trigger the inspector's "pause on uncaught exception". |
It would actually be same-tick. The Overall my initial feeling was that this API doesn't make sense in Node since Node has made a choice to handle uncaught exceptions so differently than browsers do. I.e., trying to write isomorphic code around exceptions seems like something you'd want to actively discourage. However @benlesh's comments in whatwg/html#1196 (comment) indicate that at least some library authors want to have their libraries do different things in Node (crash the process) versus browsers (report the exception). I'm guessing such library authors are following a rule that they want to have the "idiomatic" behavior in each environment. So maybe it makes sense to supply such a feature after all, as long as isomorphic-code authors understand how the behavior differs and consciously choose to use the feature with that in mind. |
This is correct. If the crash behavior was same-tick (yet uncatchable) in node, that might be beneficial for people debugging dumps, etc. As it stands now, RxJS will throw all unhandled errors in |
Thinking more about this, this almost sounds like a |
I would like to step back and think about our exiting procedures. I think adding a In some mission-critical cases servers would like to shut down connections and current operations before exiting/crashing, performing a "clean" shutdown. I wrote my own module for this, but there are plenty of others: https://github.com/mcollina/close-with-grace. |
This has stalled a while ago - so closing (with the usual "if anyone feels differently feel free to reopen"). |
I just found out about The main attraction to it, over After releasing it in my library, the first thing I did was google to see if Node had it, or was thinking about adding it, and ended up here. My thought process was: I bet there are some Node users who use similar node-exception-tracking libs/services, and they'd like my library's uncaught exceptions to bubble into that machinery, just like they would in the browser. So I'd say there is interest from library authors (at least RxJS and me) for consistent error-reporting APIs across browser and Node. I mean, that's why it's nice that both browser and Node have I'm not sure I have an opinion on whether such an error should crash the Node process or not. But at a minimum, it would definitely be nice for it to push such a reported-error into As for crashing the process, it seems like the "ergonomic" thing (from my exposure to Node) is, default to crashing, UNLESS some CLI flag or other config has overridden it, OR someone has taken the effort to register the In any case, I'd love to revive this topic and see if it could push forward in some fashion. |
Ben was the initial person who pinged me about this :)
I feel strongly that whatever API we pick if it's a web standard API we should align with browsers. WHATWG has been nothing but cooperative/helpful with this sort of thing and I don't think they'd object to a second parameter (severity?) if it makes sense for browsers (which I believe it does?). That said your other suggestion (adding an unhandledRejection handler) seems very reasonable to me.
This only stalled because of lack of feedback/interest expressed - so absolutely. |
I'll open a PR to get feedback on timing/semantics |
For my part, right now we're doing the
|
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document. |
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment. For more information on how the project manages feature requests, please consult the feature request management document. |
Refs: whatwg/html#1196
The following API was suggested for HTML:
From the top of my head, some people with opinions on these topics:
cc @ronag @mcollina @jasnell @Linkgoron @addaleax from Node.js
cc @annevk @domenic from whatwg about whether or not this makes sense from that angle
cc @benlesh for general interesting feedback and a library author PoV and for suggesting this
One big consideration here is that Node.js error handling model is different, if
reportError
doessetTimeout(() => { throw e; }, 0);
it's less a "report an error" and more a "crash the process with this uncauight exception".One upside is that this API can let us provide better developer experience than a
throw
in asetTimeout
since we can (in theory) preserve the stack and more information about the error state.The text was updated successfully, but these errors were encountered: