Can a function either return a promise, or not?

Question

So that the caller of the function (the user of the service) can use .then if he wants to do something with the information the function generates. If he doesn't care when it gets done, as long as it gets done sometime, he can just call the function without any .then infrastructure.

Will this work? I don't want to get into a situation where it will work in my tests, but in some obscure situation that doesn't happen very often, it will fail.

---

Hmm. I guess what I mean is this. If I am writing the routine that returns the promise, I have to say:

return new Promise(function (resolve, reject) { ... });

If my caller doesn't say:

.then(function () { ... }, function () { ... });

what will happen? I will at some point call resolve() or reject(), and resolve and reject won't be defined. Does the Promise constructor supply some default (do nothing) definition?

I suppose if I am a crazy person, I can say in my callee function:

(resolve || function () {})();

Answer 1

A function that returns a promise will do what you'd like it to do.

Given a function B():

If the user does not chain B().then(), they will get the answer eventually whenever it is done. It is up to them to handle the fact that they don't know when the value is populated. That is to be expected.

If the user does chain B().then(), they will have a nice and easy way to control what happens once the value is returned.

You do not need to worry about weird edge cases. A function that returns a promise is a clear and straightforward contract.

Answer 2

As with all functions in Javascript, the caller is free to ignore a return value. The Javascript garbage collector will take care of objects or values that are no longer in use.

So, if the caller of some async operation that returns a promise really doesn't care when it's done OR if there are errors, then the caller is free to just ignore the returned promise. Nothing bad happens (other than the fact that you may never know there are errors).

The part of your question that does not seem to be cool with this is where you say: "If he doesn't care when it gets done, as long as it gets done sometime" . If you are ignoring async errors, then this may not actually get done sometime and you may never know that. In this case, it might be more appropriate to do:

someAsyncFunc(...).catch(function(err) {
    console.err(err);
    // so something meaningful with the error here
});

Answer 3

Unless you specifically need to wrap a legacy API, using the Promise constructor is an antipattern. Use the Promise factories instead, or if using bluebird , see if you can use bluebird's promisify on the legacy function.

You also seem to be misunderstanding what the parameters to the Promise constructor function argument are. They are not the callbacks, they are the functions that settle the Promise. The Promise itself will worry about notifying any callbacks, if they exist.

Also, if your function sometimes returns a Promise , and sometimes does not, you might crash any code that assumes it can call .then on your function's return value. Don't do that.

If your computation may be async, always return a Promise . If you want to return a value that is already settled, then return Promise.resolve(theValue) .