Repository navigation
Console class ignores ignoreErrors on Node.js v14.3.0 #33628
Description
- Version: Node.js v14.3.0
- Platform: Linux annoMachine 4.18.0-16-generic test: make realpath tests case-insensitive on win32 #17~18.04.1-Ubuntu SMP Tue Feb 12 13:35:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
- Subsystem: console, stream
What steps will reproduce the bug?
- Create a
repro.jswhich contents is below:
ws = require('fs').createWriteStream('./foo.log');
ws.destroy();
c = new require('console').Console({
stdout: ws,
stderr: ws,
ignoreErrors: false
});
c.log("should fail");- Run
ndoe repro.js
How often does it reproduce? Is there a required condition?
Every time it reproduces on the above environment with the above procedure.
What is the expected behavior?
Invoking c.log should throw error, since the underlying streams are already destroyed, like below:
events.js:287
throw er; // Unhandled 'error' event
^
Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
Note) The expected errors are thrown on Node.js v12.16.3 and v10.20.1.
What do you see instead?
No errors thrown, and script runs succesfully.
It seems that Console class ignores ignorErrors option.
Activity
[-]Console class do not respect ignoreErrors on Node.js[/-][+]Console class do not respect ignoreErrors on Node.js v14.3.0[/+][-]Console class do not respect ignoreErrors on Node.js v14.3.0[/-][+]Console class ignores `ignoreErrors` on Node.js v14.3.0[/+]BridgeAR commentedon May 29, 2020
@ronag PTAL
XadillaX commentedon May 29, 2020
It seems because of
do not throw error any more.
ronag commentedon May 29, 2020
This is expected. You can't error an already destroyed stream. #29197
exoego commentedon May 29, 2020
So, errors thrown on Node.js v12 & v10 were bug, that was fixed somewhere on v13/v14 ?
XadillaX commentedon May 29, 2020
But I think it's a breaking change.
ronag commentedon May 29, 2020
Yes, it was labeled as semver-major.
ronag commentedon May 29, 2020
Not sure exactly what you mean. A lot of things fall under that description. But this specific case wasn't a bug per se, but it was ambiguous/undefined behavior that we changed to make it predictable. There were also other problems this caused that the change resolved.
It was a very long discussion as you can notice from the PR and not at decision taken lightly.
exoego commentedon May 29, 2020
Thanks for quick response 👍
I saw there was long disucssion in #29197, and the change seems reasonable to me.
My understanding is that the error I saw on Node.js v12 were due to ambiguous/undefined hehaviors.
I am closing this issue as "as-designed" or similar.