jdonaldson / promhx

A promise and functional reactive programming library for Haxe
MIT License
145 stars 24 forks source link

Problems with error conversion and propagation #86

Open dionjwa opened 6 years ago

dionjwa commented 6 years ago

I'm trying to catch a raw error, and convert it to a more useful error. Something like:

doSomethingReturningAPromise()
  .errorPipe(function(err) {
    //This error is not helpful. My own errors are better because they are haxe enums
    var myNicerError = convert(err);
    //Now I want to re-throw this, so it will be correctly propagated
    //to downstream error handlers
   //but how 

  //Neither of these work:
   var p = new DeferredPromise();
    // p.throwError('Some new thrown error');
    Node.setTimeout(function() {
      p.boundPromise.reject('errorPiped boundPromise reject');
    }, 50);

    return p.boundPromise;
  })
  .then(function(stuff) {
  })
   .then(function(stuff) {
  })
  .catchError(function(err) {
    //Final handler. If err is a fancy error I can:
    switch(err) {
      //Nice compile time checked error handling
    }
  })

The examples that do something similar involve catching the error, using haxe's nice catch type checking, and rethrowing. But that cannot work here because the return type of Promise.catchError() is an AsyncBase, and errorPipe doesn't handle errors throw in it, or from promises it returns.

So I'm confused if this is possible. It seems like a reasonable use case, but I'm a bit stumped.

dionjwa commented 6 years ago

Basically, I want a conditional catch/errorPipe: when I examine the error, I may want to rethrow, or convert to a non-error.

jdonaldson commented 6 years ago

This sounds reasonable. I could provide some kind of errorMap() function that just lets you map the error type and automatically rethrow. Another alternative is just to do a try/catch around the error handler methods as well, and let you manually rethrow within those.

dionjwa commented 6 years ago

That would be great. errorMap sounds clear, but it's not clear what the second approach would look like.

jdonaldson commented 6 years ago

Yeah, the second approach wouldn't work. The catchError function isn't designed to propagate errors, only handle them. I'll look into errorMap.