Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

errors: should we raise assersions for type checks in process.bindings? #17244

Closed
joyeecheung opened this issue Nov 22, 2017 · 8 comments
Closed
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core.

Comments

@joyeecheung
Copy link
Member

To migrate the errors thrown in C++ land we currently try to collect the context in C++ then throw the actual errors in JS using utilities in internal/errors.js. The current pattern would replace code like

if (!args.Length() < 1) {
   env->ThrowError(...)
}

with

CHECK(args.Length() >= 1);

and enforce the type checks with ->To*(context).ToLocalChecked().

The JS layer would do the checks in advance and make sure the bindings are invoked correctly, but if there are people using process.bindings() with wrong types of objects, previously they got errors, now they would get assersions.

This issues is to make sure we are OK with this path forward. Otherwise we need to somehow port the stuff in internal/errors.js back to C++ land for migrating those errors.

@joyeecheung joyeecheung added the errors Issues and PRs related to JavaScript errors originated in Node.js core. label Nov 22, 2017
@joyeecheung
Copy link
Member Author

cc @nodejs/tsc @jasnell

@targos
Copy link
Member

targos commented Nov 24, 2017

I'm OK with this.

addaleax pushed a commit that referenced this issue Dec 1, 2017
Squashed from multiple commits:

- src: replace ->To*(isolate) with ->To*(context).ToLocalChecked()

- test: use .As<Object> on Exception::Error

  > Exception::Error always returns an object, so e.As<Object>() should also work fine
  See #17343 (comment)

- test: use .As<Object> instead of ->ToObject

  we already checked that its a buffer

- src: use FromMaybe instead of ToLocalChecked

  It fixed this test case: 19a1b2e

- src: pass context to Get()

  Dont pass Local<Context> is deprecated soon.
  So we migrate to maybe version.

- src: return if Get or ToObject return an empty before call ToLocalChecked

Refs: #17244
PR-URL: #17343
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
@fhinkel
Copy link
Member

fhinkel commented Dec 4, 2017

I'm ok with this. Nit: there's a CHECK_GE(length, 1) macro we should use.

@mhdawson
Copy link
Member

mhdawson commented Dec 4, 2017

I'm generally ok, the only concern is if this will cause significant breakage for existing users. I guess though that in either case they would have been doing something incorrect and my first guess is that there should not be too much code catching the error and just continuing.

@MylesBorins
Copy link
Contributor

Would it make sense to do an initial naive implementation and run that against citgm?

@joyeecheung
Copy link
Member Author

@MylesBorins I think #17334 pretty much handles most of the type check migration

@mcollina
Copy link
Member

mcollina commented Dec 8, 2017

I am 👍 with the approach, independently off the breakage.

MylesBorins pushed a commit that referenced this issue Dec 12, 2017
Squashed from multiple commits:

- src: replace ->To*(isolate) with ->To*(context).ToLocalChecked()

- test: use .As<Object> on Exception::Error

  > Exception::Error always returns an object, so e.As<Object>() should also work fine
  See #17343 (comment)

- test: use .As<Object> instead of ->ToObject

  we already checked that its a buffer

- src: use FromMaybe instead of ToLocalChecked

  It fixed this test case: 19a1b2e

- src: pass context to Get()

  Dont pass Local<Context> is deprecated soon.
  So we migrate to maybe version.

- src: return if Get or ToObject return an empty before call ToLocalChecked

Refs: #17244
PR-URL: #17343
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
MylesBorins pushed a commit that referenced this issue Dec 12, 2017
Squashed from multiple commits:

- src: replace ->To*(isolate) with ->To*(context).ToLocalChecked()

- test: use .As<Object> on Exception::Error

  > Exception::Error always returns an object, so e.As<Object>() should also work fine
  See #17343 (comment)

- test: use .As<Object> instead of ->ToObject

  we already checked that its a buffer

- src: use FromMaybe instead of ToLocalChecked

  It fixed this test case: 19a1b2e

- src: pass context to Get()

  Dont pass Local<Context> is deprecated soon.
  So we migrate to maybe version.

- src: return if Get or ToObject return an empty before call ToLocalChecked

Refs: #17244
PR-URL: #17343
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
@joyeecheung
Copy link
Member Author

This can be closed now since #17334 has landed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core.
Projects
None yet
Development

No branches or pull requests

6 participants