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

@addaleax made your suggested changes, still this open question:

Actually, I'm not convinced the second commit is correct.

If a C++ API called from js has an openssl error occur, then while creating the error object to throw from C++, it calls into user-land js, and THAT throws, which error should actually suface? With all the Maybe checking, I made it be the "pending" low-level error. That was a useful exercise, it gives me a better understanding what all the Maybe's are about, but I have to say, I'm not sure its what I would expect.

In this case, isn't it the first error, the openssl API one, that we would want thrown? Not the second one?

@sam-github Yeah, I don’t think there’s a definite right or wrong answer. But I think forwarding the setter exception is what would happen if we were to do this in JS land (unless there are explicit try/catchs), and it might also be odd to throw an “incomplete” OpenSSL error object otherwise?

@addaleax the analogy with js is not entirely perfect, because the openssl error is not (yet) an exception, but it is an "error". The properties are doced as "exist if they do" (lots of crypto errors don't come from openssl, so don't have the properties), so that isn't a problem, but I'll leave it as it is, throwing the first pending exception. Its a total fringe case, its hard to imagine anyone attaching throwing setters on the global object prototype and expecting deterministic behaviour.

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

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

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

Landed in 69140bc