tls_wrap: migrate synchronous errors

[joyeecheung]

tls_wrap: migrate C++ errors to internal/errors.js

• Throw ERR_TLS_SNI_FROM_SERVER when setting server names on a
  server-side socket instead of returning silently
• Assert on wrap_->started and wrap_->ssl instead of throwing
  errors since these errors indicate that the user either uses
  private APIs, or monkey-patches internals, or hits a bug.

tls_wrap: migrate argument type-checking errors

• Throw ERR_INVALID_ARG_TYPE from public APIs
• Assert argument types in bindings instead of throwing errors

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

tls, errors

[joyeecheung]

cc @jasnell @nodejs/tsc

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

[addaleax]

It just needs to be a StreamBase, even if LibuvStreamWrap is the common case here.

[joyeecheung]

@addaleax I thought about checking the type of handle here but there doesn't seem to be a way of checking those in JS land since there isn't a proper inheritance of StreamBase.

[addaleax]

@joyeecheung Yeah, externalStream doesn’t really tell you what kind of thing it is. :/

Ideally, what we could do is making the StreamBase inheritance hierarchy reflected in the actual JS handle classes; that requires more work than this PR, though…

[joyeecheung]

@addaleax Yeah that should probably better be done in a dedicated PR IMO

[maclover7]

Should these be throw errors.TypeErrors instead of asserts?

[joyeecheung]

@maclover7 I tried that before and the test looked really dubious. These are not user-facing errors, whoever hits then either is using the underscored API or patching internals incorrectly, or is hitting a bug. Either way assertions seem to be more appropriate.

[indutny]

LGTM

…

On Fri, Jan 12, 2018 at 7:46 PM Joyee Cheung ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In lib/_tls_wrap.js <#18125 (comment)>: > @@ -407,7 +410,12 @@ TLSSocket.prototype._wrapHandle = function(wrap) { const context = options.secureContext || options.credentials || tls.createSecureContext(options); - const res = tls_wrap.wrap(handle._externalStream, + const externalStream = handle._externalStream; + assert(typeof externalStream === 'object', @maclover7 <https://github.com/maclover7> I tried that before and the test looked really dubious. These are not user-facing errors, whoever hits then either is using the underscored API or patching internals incorrectly, or is hitting a bug. Either way assertions seem to be more appropriate. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#18125 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOjw2op6S37uxsZzpAEi3QydHUT1Sjvks5tJ_zlgaJpZM4RczA6> .

[joyeecheung]

Updated since #17882 has landed and introduced a check on a changed error. The assertion is probably equally unhelpful as before but since tls.createSecurePair() is deprecated I think it's fine not to add another error code for it.

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

[joyeecheung]

CI is green. Can you take a loot again? Thanks! @addaleax @indutny

[indutny]

LGTM, as long as CI is happy

[joyeecheung]

Landed in f75bc2c...1c29da8, thanks!