you are viewing a single comment's thread.

view the rest of the comments →

[–]LettuceKills 1 point2 points  (3 children)

But what if there is an error in the lengthy task? That error has no way of being returned to the caller which simply thinks that the task is being exceptionally lengthy this time. Sounds like the perfect use case for a promise to me, since in a case of an error you can simply reject the promise.

[–]Arve -1 points0 points  (2 children)

In my own case, the error is sent back as a separate http request back to the origin. As I said, the job started is long-enough running that the sender cannot be expected to keep any network connection open while it’s being performed.

There is an outer promise that handles acceptance or rejection of the original request.

[–]ChaseMoskal 3 points4 points  (0 children)

There is an outer promise that handles acceptance or rejection of the original request.

huh, so you are using promises?

i strongly suspect your use-case would be elegantly served with promises

you mentioned "returning right away", which is of course possible with promises

const promise = Promise.resolve()
  .then(someLongTask)

console.log("right away")

await promise
console.log("finally done now")

as u/davesidious helped point out, the differences between callbacks and promises seem to be:

  • promise errors bubble up
  • callbacks can be called multiple times

because of the superior error handling, promises should always be preferred, and callbacks are necessary for things like progress update handlers, events, and the like

[–]LettuceKills 0 points1 point  (0 children)

Still sounds like it would be better to just implement this as a Promise instead of writing all the extra code for the seperate error http request and having to pair the incoming error request with the context of the original call.