doc: error event is optionally emitted after .destroy()

[tadjik1]

error event on each kind of stream is optionally emitted when .destroy() method is called. It depends on ._destroy() implementation. In default implementation this event will no be fired unless error parameter has been provided.

It was already mentioned for writable.destroy([error]), so I just copied same sentence for the other streams.

Checklist

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

[vsemozhetbyt]

CI-lite: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/2868/

[Trott]

"optionally" makes it sound like it's an option chosen by the user, but this really means "emit an 'error' event if there is an error", right?

Just a suggestion for improvement but not blocking this change. What is here is already an improvement over what's currently in the docs now.

[tadjik1]

@Trott good catch! that's true, it's not about user to decide whether or not emit this event.
however it's not 100% true that this behaviour depends on error argument - this is the default implementation, but it could be overrided:

const readable = new stream.Readable({
read() {},
_destroy(err, cb) {
// won't pass error further -> no event will be fired cb();
}
});

In this case even if you pass Error in readable.destroy() it won't emit this event.

[tadjik1]

Working on #26638 I've realised that in some situations streams are not emitting close event. Option emitClose could prevent this. So this phrase always emit a "close" events is also wrong.

[mcollina]

cc @nodejs/streams

[mcollina]

LGTM

[vsemozhetbyt]

CI-lite: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/2982/

[vsemozhetbyt]

Landed in 78162ad
Thank you!