Napi::TypeError::New is not an instanceof TypeError

[rynz]

Consider:

Napi::Value Rwar(const Napi::CallbackInfo& info) {
  Napi::Env env = info.Env();
  Napi::TypeError::New(env, "Wrong number of arguments")
      .ThrowAsJavaScriptException();
  return env.Null();
}

test('throws wrong number of arguments', () => {
  expect.assertions(1)
  try {
    addon.rwar()
  } catch (err) {
    expect(err).toBeInstanceOf(TypeError)
  }
})

For whatever reason I am getting:

● throws wrong number of arguments

    expect(received).toBeInstanceOf(expected)

    Expected constructor: TypeError
    Received constructor: TypeError

       6 |     addon.rwar()
       7 |   } catch (err) {
    >  8 |     expect(err).toBeInstanceOf(TypeError)
         |                 ^
       9 |   }
      10 | })
      11 | 

Whenever I check err instanceof Error or err instanceof TypeError both return false. Is there something I am doing wrong, or is this a bug?

[mhdawson]

I don't see anything obviously wrong with the node-addon-api or N-API code in core, looks like they should create a TypeError. What kind of object are you receiving and any more info in it that might help figure out what is going on?

[rynz]

@mhdawson I've created an example rynz/node-addon-api-exception-example

That's the thing, it is receiving an Error/TypeError and the prototype chain looks okay. I've added a test to compare N-API vs Javascript debug.

  node-addon-api
    ✕ throws wrong number of arguments (2 ms)
  javascript
    ✓ throws wrong number of arguments (1 ms)

  ● node-addon-api › throws wrong number of arguments

    expect(received).toBeInstanceOf(expected)

    Expected constructor: TypeError
    Received constructor: TypeError

       8 |     } catch (err) {
       9 |       debugger
    > 10 |       expect(err).toBeInstanceOf(TypeError)
         |                   ^
      11 |     }
      12 |   })
      13 | })

[mhdawson]

Thanks for putting together the example, I'll try to take a look next week.

[NickNaso]

Hi everybody,
today I did some attempts using the example prepared by @rynz.
I created a simple index.js file like reported below:

'use strict'

const addon = require('./lib/rwar')
const assert = require('assert')

try {
  addon.rwar()
} catch (err) {
  assert.strictEqual(typeof TypeError == 'function', true)
  assert.strictEqual(err instanceof TypeError, true)
  assert.strictEqual(err instanceof Error, true)
  assert.strictEqual(typeof err.constructor === 'function' && err.constructor == TypeError, true)
  assert.strictEqual(typeof err.constructor === 'function' && err.constructor == Error, false)
}

I tried to replicate the checks that jest do on toBeInstanceOf and they produced the expected results.

[mhdawson]

I was also just looking at this. Using plain old instanceof gives the expected answer:

const addon = require('../rwar')

try {
  addon.rwar()
} catch (err) {
  console.log(err);
  console.log(err instanceof TypeError);
}

-sh-4.2$ node test.js
TypeError: Wrong number of arguments
at Object. (/home/mhdawson/test/node-addon-api-exception-example/lib/tests/test.js:4:9)
at Module._compile (internal/modules/cjs/loader.js:1217:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1238:10)
at Module.load (internal/modules/cjs/loader.js:1066:32)
at Function.Module._load (internal/modules/cjs/loader.js:954:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
at internal/main/run_main_module.js:17:47
true

[NickNaso]

I'm trying to execute the some tests with other test suite like:

• node-tap:

'use strict'

const tap = require('tap')
const addon = require('./lib/rwar')

const test = tap.test

test('test 1', (t) => {
  try {
    addon.rwar()
  } catch (err) {
    t.match(err, TypeError)
  }
  t.done()
})

test('test 2', (t) => {
  const fn = function() {
    return addon.rwar()
  }
  t.throws(fn, TypeError)
  t.done()
})

• jasmine

'use strict'

const addon = require('./lib/rwar')
describe('Test addon', function () {
  it('Schould be TypeError', function() {
    try {
      addon.hello()
    } catch (err) {
      expect(err).toBeInstanceOf(Error)
      expect(err).toBeInstanceOf(TypeError)
    }
  })
})

All continue to work as expected. Do you know if with jest we need some particular configuration?

[mhdawson]

I'm wondering if jest does some instrumentation of TypeError that's getting in the way.

[NickNaso]

Hi everybody,
I provided to open an issue on jest repo hope that hey give us some suggestion about. The issue is jestjs/jest#10189

[mhdawson]

@NickNaso great idea, I think we need somebody with knowledge of jest to comment.

[mhdawson]

The root cause may be related to the same issue in #764. The effects of JEST using different contexts.

[mhdawson]

Does seems related to JEST using contexts. This test recreates the behavior reported:

const addon = require('../rwar')
const vm = require('vm');

try {
  addon.rwar();
} catch (err) {
  console.log('Regular context:' +  (err instanceof TypeError));
}

try {
  const contextObject = { };
  vm.runInNewContext("addon.rwar()", contextObject);
} catch (err) {
  console.log('New context:' + (err instanceof TypeError));
}

[mhdawson]

@rynz you can read a bit more on the details in #764 but this seems to be an expected result of Node.js (not specific to N-API) not supporting multi-Context addons and the use of vm.runInNewContext by Jest.

[rynz]

@mhdawson thank you. What is the use-case of multi-context with node.js?

[mhdawson]

In terms of "multi-context" I think "context" might be a bit overloaded. I do know that there is/was work to let add-ons work nicely with Worker Threads such that you have ways to easily store data which is not global but instead specific to the worker thread from which the add-on is called. Sometimes I think I've seen this referred to as multi-context or something similar as well. That's one use case.

In terms of the question you raised in this issue, the use case is doing things like calling in vm.runInNewContext and getting what you expect if it had been JavaScript code versus native code.

Not sure this helped to clarify. @gabrielschulhof do you have a better explanation?

[mhdawson]

Some discussion in the N-API meeting today and its a bit less clear as I may not have gotten a good test case. Will try to update the test case a bit later today.