Skip to content

uncaughtException only catches the first uncaughtException. #5147

Closed
Closed
uncaughtException only catches the first uncaughtException.#5147
Labels
processIssues and PRs related to the process subsystem.

Description

@NoahRoseLedesma
NoahRoseLedesma
opened on Feb 9, 2016

Example:

process.on('uncaughtException', (err) => {
  console.log(`Caught exception: ${err}`);
  causeError();
});

function causeError(){
console.log(notDefined);
}
causeError();

Output:

Caught exception: ReferenceError: notDefined is not defined
C:\fail.js:7
console.log(notDefined);
            ^

ReferenceError: notDefined is not defined
    at causeError (C:\fail.js:7:13)
    at process.<anonymous> (C:\fail.js:3:3)
    at emitOne (events.js:77:13)
    at process.emit (events.js:169:7)
    at process._fatalException (node.js:223:26)
[Finished in 0.256s]

Tested on 64 bit Windows, and Ubuntu. Versions 4.2.3 and 0.10.41

Activity

  1. mscdex
    added
    processIssues and PRs related to the process subsystem.
    confirmed-bugIssues and PRs for confirmed bugs.
    on Feb 9, 2016

  2. mscdex commented on Feb 9, 2016

    @mscdex
    mscdex
    on Feb 9, 2016
    Contributor

    This happens with v5 and master as well. Delaying the second causeError() until the next tick does work as expected though.

    Perhaps this is intentional though, since otherwise it'd lead to an infinite loop?

  3. mscdex
    removed
    confirmed-bugIssues and PRs for confirmed bugs.
    on Feb 9, 2016

  4. bnoordhuis commented on Feb 9, 2016

    @bnoordhuis
    bnoordhuis
    on Feb 9, 2016
    Member

    Exactly. Working as intended, as far as I'm concerned.

  5. misterdjules commented on Feb 9, 2016

    @misterdjules
    misterdjules
    on Feb 9, 2016

    Yes, the initial implementation of how the process' uncaughtException event is emitted had a guard against recursive calls. The current implementation also clearly avoids it, so it seems this works as intended.

    @NoahRoseLedesma Is that a problem?

  6. NoahRoseLedesma commented on Feb 9, 2016

    @NoahRoseLedesma
    NoahRoseLedesma
    on Feb 9, 2016
    Author

    That isn't a problem, waiting until the next tick as @mscdex suggested works as intended.
    It would be helpful to have this safeguard noted in the documentation for this event.

  7. misterdjules commented on Feb 9, 2016

    @misterdjules
    misterdjules
    on Feb 9, 2016

    @NoahRoseLedesma

    That isn't a problem, waiting until the next tick as @mscdex suggested works as intended.

    Please note however that the documentation mentions:

    'uncaughtException' should be used to perform synchronous cleanup before shutting down the process.

    So waiting until next tick is outside of this recommendation.

    It would be helpful to have this safeguard noted in the documentation for this event.

    Absolutely, would you be interested in submitting a pull request for that?

  8. evanlucas commented on Feb 22, 2016

    @evanlucas
    evanlucas
    on Feb 22, 2016
    Contributor

    Closing as the documentation PR has landed. Thanks!

  9. evanlucas
    closed this as completedon Feb 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    processIssues and PRs related to the process subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions