Repository navigation
Can we refactor opensslErrorStack? #16521
Description
Activity
I am unable to find any mentions of the property in use anywhere (GitHub and Google searches show no mentions of the property outside of our own errors.md doc and test-crypto.js file).
That's because it was only added last month: #15518
Ugh. That's right. I thought it looked familiar. I hadn't managed to get back around to reviewing that pr and totally forgot about it. Given that it's so new, then, perhaps we can refactor it a bit. As it stands it makes converting to internal/errors more difficult
-1 to deprecating. The most recent OpenSSL error on the error stack is not always very helpful, so having the rest of the stack available can shed light on what the problem actually is.
BTW I was the one who initially requested this extra information be made available in one form or another.
Reminder to self: git blame is your friend
Reacted by Bryan English- changed the title
[-]Can we deprecate opensslErrorStack?[/-][+]Can we refactor opensslErrorStack?[/+]on Oct 26, 2017 Changed the title of this to refactor rather than deprecate. I'd like to see if there's a better way for us to surface these details that would make the migration to internal/errors easier...
Errors thrown from inside node_crypto might contain an additional
opensslErrorStackproperty. This property is generally undocumented save one reference here and I am unable to find any mentions of the property in use anywhere (GitHub and Google searches show no mentions of the property outside of our own errors.md doc and test-crypto.js file).Keeping it around seems significantly less than useful. I propose deprecating the property and changing things such that if (and only if) we are in a DEBUG build, the openssl stack trace can be output to the console immediately before the associated js error is thrown.
@nodejs/crypto @nodejs/tsc