Skip to content

More (unnecessary?) NAPI_PREAMBLE() calls #238

Description

@gabrielschulhof

We have

  • napi_is_array (val->IsArray())
  • napi_is_buffer (node::Buffer::HasInstance())
  • napi_is_arraybuffer (val->IsArrayBuffer())
  • napi_is_typedarray (val->IsTypedArray())

that have NAPI_PREAMBLE(), whereas

  • napi_is_error (val->IsNativeError())

does not have it.

I don't believe the ones above that have NAPI_PREAMBLE() need it, for the same reason that napi_typeof() doesn't need it. What do @nodejs/addon-api think?

Activity

  1. mhdawson commented on Apr 27, 2017

    @mhdawson
    Member

    If you have checked and don't believe we need them there, I'm happy to have them be removed.

  2. gabrielschulhof commented on Apr 27, 2017

    @gabrielschulhof
    CollaboratorAuthor

    The only thing I'm not sure about is whether the engine would ever throw an exception in response to IsArrayBuffer(), or IsArray() or functions of this nature. I think I'll remove the NAPI_PREAMBLE()s, because it doesn't make sense to me that it should ever throw an exception in such cases.

  3. jasongin commented on Apr 27, 2017

    @jasongin
    Member

    +1

    The four listed above seem the most obvious, though we may also consider several other APIs that don't have any possibility of invoking JavaScript code. Does V8 ever throw exceptions when not invoking JS code? I assume not.

  4. gabrielschulhof commented on Apr 27, 2017

    @gabrielschulhof
    CollaboratorAuthor

    OK, so while we're on the topic, what about these:

    • napi_get_value_string_latin1
    • napi_get_value_string_utf8
    • napi_get_value_string_utf16
    • napi_get_value_external
    • napi_get_buffer_info
    • napi_get_arraybuffer_info
    • napi_get_typedarray_info
      We should test how these functions behave if we pass in the wrong type, or, better yet CHECK_TO_<type> at the top.
  5. jasongin commented on Apr 27, 2017

    @jasongin
    Member

    better yet CHECK_TO_ at the top

    Generally we have avoided automatic type coercions, because they can have a significant perf cost. (I think there may even be a few places currently doing type coercions that shouldn't.) If the wrong type is passed into an API, it should just return an appropriate error code.

  6. jasongin commented on Apr 27, 2017

    @jasongin
    Member

    And yes, I agree with adding all those getters to the list.

  7. gabrielschulhof commented on Apr 27, 2017

    @gabrielschulhof
    CollaboratorAuthor

    They all have checks, so that's good.

  8. gabrielschulhof commented on Apr 27, 2017

    @gabrielschulhof
    CollaboratorAuthor

    Yeah, sorry, I meant type checks, not coercions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    Sponsor
    SponsoredKunjungi sekarang
    Promo