Don't catch errors in resolve fns, chains, etc...

[jordalgo]

Unnecessary error catching is something that, IMO, we should avoid in Future/Task implementations. e.g.

function createFuture() {
  return new Future(function computation(reject, resolve){
    setTimeout(() => {
      resolve('hello');
    }, 0);
  });
}

createFuture().fork(
  left => { console.log('left', left.message); },
  right => { console.log('right', right); throw new Error('boom'); }
);

This example will log in the console:
right hello
left boom

This is not good as it's completing the future twice and mixing rejections with unexpected errors (something that Promises do). If there is code that might be prone to throwing an error (such as JSON.parse or accessing nested props in an object) THAT code should get wrapped in a try/catch. The Future/Task should have no opinion on error catching.

[davidchambers]

+:100:

[Avaq]

Related:

• Improve Future try-catching #79 - My PR which strengthened this behavior in Ramda Fantasy :(
• FunTask exception philosophy (good read)
• Fluture exception philosophy

[jordalgo]

@Avaq Thanks for the links. I had read @rpominov 's philosophy a little while ago and I agree 100%. It also seems like you agree which is why you don't have any special error handling in Flutures. What do you think about removing it for Ramda's Future?

On a related topic (and I can move this into a separate issue), is there any spec out there for Futures/Tasks in javascript and if not, is it worth making one? It's probably not completely neccesary but it might be nice to standardize this type in some way (fork vs run, error handling, Future or Task, etc...) similar to the work going on with Observables -- though I feel like standardizing on Future/Task would be MUCH easier 😜

[Avaq]

I believe this can be closed. Ramda Fantasy has been discontinued, and recommends using Fluture. Fluture doesn't mix exceptions into the rejection branch.

I don't think standardising Future continuation is beneficial in the long run (see Promises). It's nice that the community can come up with different ways of abstracting over asynchronous computations.

Work is being done to standardise catamorphism though, which comes close.