Handle Error cases

Any thoughts on how to handle errors in a stream? For example, if a promise is rejected, from what i saw in code the stream will never be triggered, since the promise only invoke like this n.then(s) //line 134.

I try to improve this, but have not come up a rational solution. Should stream just end itself when it encounters an error, or should it provide a way to be listened to its errors?

[paldepind]

This is a great question and I’m aware that the documentation doesn’t describe errors at all 😦

My current opinion is that Flyd should not concern itself with error handling. I don’t see any benefit in doing so.

For normal synchronous code developers know how to handle errors. You need to handle that some functions might return null/undefined in certain cases and if you’re using functions in a way so they might throw you use try/catch. Promises offers similar features for asynchronous code.

You know all of the above of course. But that Flyd doesn’t do any n.catch(someErrHandler) might still seem like a problem to you. This is why I don’t think it’s a problem. First consider an example with synchronous error handling:

var userStringStream = flyd.stream(); // user information that should be formatted as JSON
var userData = flyd.map(function(userString) {
  try {
    return JSON.parse(userString);
  } catch (err) {
    return emptyUserData;
  }
}, userStringStream);

The above is pretty straight forward. We do an operation that might throw JSON.parse. If it doesn’t throw the stream is set to it’s return value and if it does some default data is used instead. The same thing can be achieved with promises today:

var userDataUrl = flyd.stream(); // and URL from which user information can be loaded
var userData = flyd.map(function(url) {
  return fetch(url).catch(function(err) {
    return emptyUserData;
  });
});

Is you’ve properly noticed and mentioned Flyd doesn’t handle rejected promises. The idea is that you should never send promises that might reject down a stream. This is achieved by adding catch handlers to your promises before you return them to a stream.

The benefits of the above method is:

• Flyd stays simple
• One doesn’t have to learn anything new about errors handling
• All the powerful error handling than one normally uses works well with Flyd

This is my current thinking and this is what I’ve done until know. But this is not set in stone. If you see any problems with the above approach by all means express your concerns!

[squiddle]

could it be useful to provide an error stream like the end stream? So for proper error handling the suggested solution should be using either. The error stream would allow to have error handling for errors in flyd or its modules (which should not handle Either so they must handle all errors).

i like the decision to move the usage of either out of the scope of flyd. Even though it probably means every own function (eg. a map fn) which just needs to pass errors along, would need to be wrapped with a curried fn of Either.chain(func, either) (if the func takes the values in the stream) or flyd.map(Either.chain(func)) (if the func takes the streams).