2

When you have a Promise based function like so:

function foo() {
  return new Promise(function(fulfill, reject) {
    // Do some async work, and then...
    console.log('a');
    fulfill('b');
    console.log('c');
  });
}

You'll notice that c will get printed after the fulfill statement, implying that the function does not break upon fulfill or reject. This is troublesome since most logic would assume that the function should end once it has called fulfill() or reject().

Question:
Is it safe or standard usage to then simply add return before the fulfill() or reject() call?

function foo() {
  return new Promise(function(fulfill, reject) {
    // Do some async work, and then...
    console.log('a');
    return fulfill('b');
    console.log('c'); //Does not get printed, as the function has ended execution. 
  });
}

// Call the function:
foo()
  .then(function(response) {
    console.log(response); //This is called once the function calls fulfill, will print 'b'
  });

Are there any issues with using Promises like that? Most promise information online makes no reference to using the return statement before fulfill or reject. As an additional side question, what is the most common way to use indentation when using then and catch?

  • I can't see a reason not to do this, maybe not best practice but safe? yes. – Rich Jun 05 '16 at 09:16
  • In general, yes, but your particular example doesn't make sense. You shouldn't use promises for synchronous tasks, and you should just drop the `console.log('c')` instead of making it dead code by putting a `return` in the line before. – Bergi Jun 05 '16 at 10:48
  • @Bergi the promise example was just an example, hence the synchronous task. Did you read the question? –  Jun 05 '16 at 13:17
  • @love: Yes, I read the question, and closed with an (I hope) appropriate duplicate :-) Regarding "safe", that's nothing to do with promises, `return` has just the usual semantics in the callback function. – Bergi Jun 05 '16 at 14:01
  • @Bergi, Yes ty for the appropriate link. I used the term safe in regards to being uncertain how implicitly returning the callback might affect the caller/flow control. It has been answered that there is no difference or adverse effects, and that it indeed should be used when wanting to end function execution. Thanks all for your time. –  Jun 05 '16 at 14:42

1 Answers1

1

Generally, in NodeJS, you shouldn't use the promise constructor very much.

The promise constructor is for converting APIs that don't return promises to promises. You should consider using a library that provides promisification (even if you use native promises all-around) since it provides a safe alternative that does not have subtle errors with error-handling logic.

Automatic promisification is also considerably faster.

That said, the answer to your question is "Yes".

It is perfectly safe to do so, there is nothing special about promise constructors - they are just plain JavaScript. Domenic discusses the design of the promise constructor in his blog.

It is perfectly safe (just like any other function) to return early - it is actually quite common in regular asynchronous functions.

(Also, in your example code you should just use Promise.resolve, but I assume it was that simple only because it is an example).

Community
  • 1
  • 1
Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
  • Thanks for your answer. Could you clarify or provide resources on two points: 1. How is `automatic promisification` considerably faster? How is it working under the hood? 2. What do you mean when you say to use `Promise.resolve` For the example in my question, you can assume that it was meant to do some async task first before `fulfill()`. Thanks again! –  Jun 05 '16 at 13:22