0

I was learning javascript Promises. To me, it looked like JavaScript Promise works similar to a callback function.

In a callback function, we usually use the first parameter as an error, and the second as a success.

Then why in JavaScript Promise, parameters come differently? First is the success and second is the error? It's like the opposite of the callback parameter structure and it confuses me.

This isn't a problem, but I would like to have an explanation for this. If I am wrong, then what am I missing?

  • the callback can accept multiple parameters, not just one success, but error can be only one so you need to have it at first also these callbacks are called `error-first callbacks`.`resolve` and `reject` are functions/callback, not variable params. – AZ_ Jan 06 '20 at 06:52
  • Because the former is who checks for an error, and the latter is who emits an error. Error checking is generally required, but error emitting is not. Hence the parameter orders. – Константин Ван Jan 06 '20 at 06:59
  • Related: https://stackoverflow.com/questions/24662289/when-is-thensuccess-fail-considered-an-antipattern-for-promises – Kaiido Jan 06 '20 at 07:07

2 Answers2

1

You're apparently talking about the Promise executor function (what you pass to new Promise(...)). That's just an entirely different type of callback and it really doesn't have anything in common with the standard node.js asynchronous callback.

The promise executor function is passing you two separate functions that you can later call. Neither is an error. When you actually have an error, you call reject(err) and you pass it the error as the first argument.

The other place that two things are passed is a .then() handler where you can pass both a resolve handler and a reject handler. Again, this is a completely different thing. You are passing it two function references and the promise infrastructure will decide which callback to pass. When it calls those callbacks, it will pass the argument as the first argument.

Here are two different callback elements in promises:

// promise executor function
let p = new Promise((resolve, reject) => {
    // this is passing to your callback two function references.
    // there's no error at this point.
    // you decide which function to call in your asynchronous operation
});

// then handler
somePromise.then(resolveData => {
    // this callback gets called when your promise resolves
    // it is known there is no error here, so no need to pass an err parameter
}, rejectErr => {
    // this callback gets called when your promise is rejected
    // the error is passed as the first argument
    // this callback is optional
});

There are also .catch() and .finally() handlers, but they work similarly taking a single callback.

Keep in mind that the pattern:

 p.then(successHandler, errorHandler)

is not passing you an error as the second argument. YOU are passing it two function references and it will call one of them as some later time. In this way, it is not like the standard nodejs asynchronous callback like fs.readFile() would use. It has a completely different purpose and works differently.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
0

You are confusing JavaScript promises callbacks with callback design patterns from the Node standard library's API. They are not the same.

The purpose of JavaScript promises is to deal with long running processes where we need some ability to figure out when the process is finished to continue running the next snippet of code.

So in the Promises callbacks that you are learning about there are 3 states: unresolved, resolved, and rejected.

By default, a Promise exists in an unresolved state, that means you just made the Promise and you are waiting for something to happen, some long running process such as an Ajax request or some other event to occur, once it occurs, that Promises enters into either one of the two other states, resolved or rejected.

The above is not the purpose and function of Node standard library's callbacks which are used inside of functions that are part of the filesystem API. These particular functions such as read(), readdir() and so on have three arguments that can be passed to it, one being optional, the third being the callback which you speak of.

The pattern for Node standard library callbacks when working with filesystem functions is to offer two arguments in that callback argument, the first one always being an error object, err, now it's not guaranteed that an error is going to occur, instead if something goes wrong when opening up some file(s), Node is going to call the callback with the first argument of the err object.

If there is no error, then the first argument is going to instead be null.

Now the second argument to the callback function is going to be the data I am actually looking for.

https://nodejs.org/api/fs.html#fs_file_system

You see, two different callbacks you are talking about.

halfer
  • 19,824
  • 17
  • 99
  • 186
Daniel
  • 14,004
  • 16
  • 96
  • 156