inspector: log exceptions in message handlers

[eugeneo]

Fixes: #14965

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

inspector: JS bindings were updated.

[eugeneo]

I am not entirely sure what to do with the exceptions here. post is the main entry point of this API, but the problem is that multiple message handlers can be called within one call to post. Some options that were considered:

1. Log exception and do not throw - this is what this PR does. This is altering current behavior where the exceptions used to be thrown from the post.
2. Throw it from process.nextTick - nextTick may never happen, e.g. if the handler has issues while handling messages while V8 is suspended.
3. Introduce 'handlerError' event on session object with the default handler that does logging.
4. Throwing first or last exception from the post. Log all other messages.
5. Stop calling the callbacks after the first exception, rethrow the exception from the post

Any suggestions on a best approach?

[jasnell]

@eugeneo ... would you consider these to be fatal events?

If so, then option 5 would likely be best, but it's also the most draconian.

If they are not fatal, then a 6th option would be to use process.emitWarning() to emit each message as a separate warning. Users can then decide for themselves how they would prefer to handle them (e.g. use the default output to stderr, redirect those to a file, register a warning handler, switch them off entirely, etc).

[eugeneo]

@jasnell Thank you for the suggestion. I definitely don't think those events are fatal - so now the code emits warnings.

[jasnell]

you can use common.mustCall(3) here to limit the number of warning events triggered.

[jasnell]

LGTM with green CI and a suggestion.

[eugeneo]

Thank you for the review, I updated the code. CI: https://ci.nodejs.org/job/node-test-pull-request/9829/

[TimothyGu]

Would it be possible to call the callbacks in a process.nextTick?

[eugeneo]

@TimothyGu I'm bit concerned it might be possible to deadlock inspector callback and never see the nextTick happen (e.g. if the bad callback is invoked while the V8 is suspended and causes an infinite loop somehow).

[TimothyGu]

@eugeneo Sounds quite complicated… I'll defer to your judgment then!

[eugeneo]

CI: https://ci.nodejs.org/job/node-test-pull-request/9879/

[jasnell]

Hmm... Getting some failures on 32-bit systems. See: https://ci.nodejs.org/job/node-test-commit-linux/12132/nodes=debian8-x86/console

[eugeneo]

@jasnell I'm fixing them - there's an unexpected warning firing there.

[BridgeAR]

CI https://ci.nodejs.org/job/node-test-pull-request/9904/

[eugeneo]

CI failures were not caused by this CL but I am not confident with this test coverage enough to merge this PR.

[jasnell]

I've added in the in progress label so folks can know not to land it until you're more comfortable with it.

[eugeneo]

CI: https://ci.nodejs.org/job/node-test-pull-request/9985/

[eugeneo]

Landed as 9bae3ea