0

As far as I can tell, the two objects failApiClient and explicitFailApiClient should have the same type, and logging them appears to agree:

console.log(failApiClient) // { getObjects: [Function: getObjects] } console.log(explicitFailApiClient) // { getObjects: [Function: getObjects] }

Reading this question gives me the information required to handle this correctly, but it doesn't tell me why the generated failApiClient causes the warning while the explicitFailApiClient does not.

I have pared this down to near the minimum required to recreate the circumstances and demonstrate working alternatives:

import * as sinon from 'sinon';
import 'source-map-support/register';

class LocalObject {
}

const fakeObject = new LocalObject();

const getFakeApi = (result: Promise<LocalObject[]>) = ({getObjects: () => result});

const successObjectClient = getFakeApi(Promise.resolve([fakeObject]));

// These should be equivalent, but the former causes a test error
const failApiClient = getFakeApi(Promise.reject(new Error()));

const explicitFailApiClient = {
  getObjects(): Promise<LocalObject[]> {
    return Promise.reject(new Error());
  }
};

describe('successApiClient', () => {
  before(() => {
    sinon.spy(successObjectClient, 'getObjects');
  });

  it('does not have a warning', async () => {
    // do nothing
  });

});

describe('failApiClient', () => {
  before(() => {
    sinon.spy(failApiClient, 'getObjects');
  });

  it('should not have a warning', async () => {
    // do nothing
  });
});

describe('explicitFailApiClient', () => {
  before(() => {
    sinon.spy(explicitFailApiClient, 'getObjects');
  });

  it('does not have a warning', async () => {
    // do nothing
  });
});

And the result of ~/...> tsc && npm test:

> internal-api@1.0.0 test /Users/./Projects/./node/internal-api
> grunt test

Running "test" task

Running "env:dev" (env) task

Running "simplemocha:unit" (simplemocha) task


(node:72101) UnhandledPromiseRejectionWarning: Error
    at Object.<anonymous> (/Users/./Projects/./node/internal-api/src/test/unit/models/mvp.test.ts:21:57)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (/Users/./Projects/./node/internal-api/node_modules/coffee-script/lib/coffee-script/register.js:45:36)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at /Users/./Projects/./node/internal-api/node_modules/mocha/lib/mocha.js:222:27
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/Users/./Projects/./node/internal-api/node_modules/mocha/lib/mocha.js:219:14)
    at Mocha.run (/Users/./Projects/./node/internal-api/node_modules/mocha/lib/mocha.js:487:10)
    at Object.<anonymous> (/Users/./Projects/./node/internal-api/node_modules/grunt-simple-mocha/tasks/simple-mocha.js:29:20)
    at Object.<anonymous> (/Users/./Projects/./node/internal-api/node_modules/grunt/lib/grunt/task.js:255:15)
    at Object.thisTask.fn (/Users/./Projects/./node/internal-api/node_modules/grunt/lib/grunt/task.js:73:16)
    at Object.<anonymous> (/Users/./Projects/./node/internal-api/node_modules/grunt/lib/util/task.js:294:30)
    at Task.runTaskFn (/Users/./Projects/./node/internal-api/node_modules/grunt/lib/util/task.js:244:24)
    at Task.<anonymous> (/Users/./Projects/./node/internal-api/node_modules/grunt/lib/util/task.js:293:12)
    at /Users/./Projects/./node/internal-api/node_modules/grunt/lib/util/task.js:220:11
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickCallback (internal/process/next_tick.js:180:9)
    at Function.Module.runMain (module.js:695:11)
    at startup (bootstrap_node.js:191:16)
    at bootstrap_node.js:612:3
(node:72101) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:72101) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
  successApiClient
    ✓ does not have a warning

  failApiClient
    ✓ should not have a warning
(node:72101) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 1)

  explicitFailApiClient
    ✓ does not have a warning


  3 passing (14ms)


Done.
Nyefan
  • 251
  • 3
  • 10

2 Answers2

1

They are not equivalent.

In the code below, JS already execute the statement Promise.reject when it is put as argument, that's why you got that early warning UnhandledPromiseRejectionWarning.

const failApiClient = getFakeApi(Promise.reject(new Error()));

Comparing to

const explicitFailApiClient = {
  getObjects(): Promise<LocalObject[]> {
    return Promise.reject(new Error());
  }
};

whose Promise.reject will be evaluated when explicitFailApiClient.getObjects() is called.

Solution

Here is my alternative solution for this matter. I can just use resolves and rejects from Sinon.

const getFakeApi = {getObjects: (result) => result};
const getFakeApiStub = sinon.stub(getFakeApi, 'getObjects');

describe('successApiClient', () => {
  before(() => {
    getFakeApiStub.resolves([fakeObject]); // success and resolves
  });

  it('does not have a warning', async () => {
    // do nothing
  });

});

describe('failApiClient', () => {
  before(() => {
    getFakeApiStub.rejects(new Error()); // make it failed
  });

  it('should not have a warning', async () => {
    // do nothing
  });
});

Ref: https://sinonjs.org/releases/v6.3.5/stubs/#stubresolvesvalue

Hope it helps

deerawan
  • 8,002
  • 5
  • 42
  • 51
0

Promises can be unresolved, resolved or rejected. "then" is used to handle a resolution where "catch" is handles a rejection. You're throwing a rejection without catching it.

Try SomePromiseRejection().catch(err => DoSomeStuff(err))

So after explicitFailApiClient is called have a .catch block.

Eddie D
  • 1,120
  • 7
  • 16
  • The `explicitFailApiClient` does not cause the `UnhandledPromiseRejectionWarning` - only the `failApiClient` does. That is the crux of what I'm trying to understand. – Nyefan Oct 05 '18 at 19:04