doc: avoid mentioning 'uncaughtException'

[lpinca]

I think we should not mention the 'uncaughtException' event in the documentation of the error events. Experience has taught me that it is usually used in the wrong way leading to bizarre situations like parsers blocked in a wrong state, events emitted multiple times when they should not, etc. If an 'error' event does not have a listener the process should just exit.

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

doc

[bnoordhuis]

Already a step up so +1 from me.

[a0viedo]

I'm not in favor of removing documentation if it's still supported but here's my concern: if user space is misusing a feature, isn't the responsibility of the docs to shed some light into misunderstandings?

[lpinca]

@a0viedo the feature is still documented and there is a dedicated section called "Warning: Using 'uncaughtException' correctly".

This only removes it from the EventEmitter documentation in an attempt to avoid suggesting using 'uncaughtException' as a replacement for missing 'error' listeners.

[Trott]

Should we link to the "Using uncaughtException correctly" section rather than (or in addition to) recommending a deprecated module? Just a question, not a blocking objection.

[lpinca]

@Trott we can but I would prefer not to. 'error' events should be handled by their respective listener(s) and nothing else. In this context, mentioning 'uncaughtException' in whatever form, is not a good idea imho.

I wanted to also remove the domain recommendation and only keep the last sentence ("As a best practice, listeners should always be added for the 'error' events.") but that seemed too much documentation removed at a single time.

[addaleax]

Landed in 9531fcb