tap analog for catch

[Artazor]

What about .tapError() with the same signature as .catch (with filters) but the following semantics? (analog to #116)

var noError = {};
Promise.prototype.tapError = function() {
    var e = noError;
    var p = this.catch(function(reason){
        throw e = reason; 
    });
    return p.catch.apply(p,arguments).then(function(value){
        if (e === noError) {
            return value;
        } else {
            throw e;
        }
    })
}

Please understand the motivation (!)

It is motivated by the TypeScript usage (@spion you are welcome to comment)
When you write a catch handler only for logging purposes you never return and always throw, but type signature of resulting promise is completely vanished. e.g.

the problem

return Promise
    .resolve("MyString")
    .then(transform)
    .catch(TransformError, (e: TransformError) => {
        console.log("Transormation failed", e.tranformFailureReason);
        throw e;
    }).then ...   // Here we have Promise<void> instead of Promise<string>

failed attempt

return Promise
    .resolve("MyString")
    .then(transform)
    .catch(TransformError, (e: TransformError): string => {
        console.log("Transormation failed", e.tranformFailureReason);
        throw e;
    }).then ...   // Does not compile with TS1.4 - error TS2355

It fails with

error TS2355: A function whose declared type is neither 'void' nor 'any' must return a value or consist of a single 'throw' statement.

Technically this approach fails only because of microsoft/TypeScript#1613 and will work as soon as static flow analysis will be implemented inTypeScript. However I suppose that it is wrong to specify a return type for this handler. It is not intended to return.

ugly yet successfull

return Promise
    .resolve("MyString")
    .then(transform)
    .catch(TransformError, (e: TransformError): Promise<string> => {
        console.log("Transormation failed", e.tranformFailureReason);
        return Promise.reject<string>(e);
    }).then ...   // Here we have Promise<string> 

proposed

return Promise
    .resolve("MyString")
    .then(transform)
    .tapError(TransformError, (e: TransformError) => {
        console.log("Transormation failed", e.tranformFailureReason);
    }).then ...   // Here we have Promise<string> !!!

Does it sound reasonable?

[Artazor]

Signature for the .tapError would be

declare class Promise<T> {
   tapError<U>(ErrorClass, handler:(reason: any) => U|Promise<U>): Promise<T>;
}

[petkaantonov]

I think this is possibly a duplicate

[Artazor]

I suspect that it can be implemented via Promise.prototype._passThrough with some Error filter magic (same as in .catch())

I think this is possibly a duplicate

At least it is not implemented. Is it?

[benjamingr]

@petkaantonov that is correct.

Duplicate of #517

[Artazor]

@benjamingr technically it resembles the duplicate. However here is absolutely different motivation and strong indications that it is a lacking functionality.

Please answer to the one question:

// Let's consider a classical signature for `catch`
Promise<T>::catch<U>((reason: any) => U|Thenable<U>) => Promise<U>

// wrap :: t -> [t]
function wrap<T>(value: T): Array<T> {
    return [value];
}

// unwrap :: [t] -> t
function wrap<T>(value: Array<T>): T {
    return value[0];
}

// (???) What signature should have the following function
function logAndThrow(e) {
   console.log(e);
   throw e;
}

// ... to be correctly used in the following chain (there should be no type-errors)
var p:Promise<string> = Promise.resolve("test")
    .then(wrap)
       .then(wrap)
         .then(wrap)
           .catch(logAndThrow)
         .then(unwrap)
       .then(unwrap)
    .then(unwrap)
    .then(wrap)
       .catch(logAndThrow)
    .then(unwrap)

@spion - you are welcome to solve this nice type-theory puzzle too :)

[petkaantonov]

@Artazor log and throw is an anti pattern that is not embraced by bluebird, that was already discussed in the duplicate thread

[benjamingr]

@Artazor your type annotations are weird, sometimes you use Haskell and sometimes you use :: for prototype method but ok. If you want implicit side effects (the logging, the type signature is simply:

Promise<T>::logAndThrow(message:String) => Promise<T>

In "Haskell":

logAndThrow:: Promise T -> String -> Promise T 

It's quite trivial, it takes a Promise and a string message and returns a Promise over the same resolution value.

Although, it's worth mentioning your Promise type signature isn't really type safe since catch takes the any type.

[Artazor]

your type annotations are weird

Sorry, my bad -) I've tried to use Haskell in comments only as a clarification.

I'm with you against logAndThrow in the catch-all style. But my question was not about logging. I'm talking about correct typing.

var x:Promise<string> = someRequest()
    .catch(LowLevelError, e => throw new BusinessError(e))
    .then(res => res.stringField)  // fails to compile

Is it a valid use-case?

[Artazor]

@benjamingr

I just want to point out that sometimes inability to assign a correct type to a function means that the function is cluttered with several responsibilities and may be split into several functions with better signatures/implementations/semantics.

Here I suspect that catch is responsible for two distinct things:

1. Recovering form the exception in previous stage (if new exception is thrown here, then it is a new fresh exception that is not expected, and is completely unrelated to the exception being caught)
2. Transforming the exception. This one is not intended to interfere with success-callbacks of the downstream. It should simply transform an existing exception into (possibly) another one.

The first one definitely should affect the signature of the resulting Promise
The last one definitely should not (in fact it should return a new Exception, instead of throwing it)

@spion, @petkaantonov ?

[Artazor]

In fact I would be happy if Promise::catchThrow could use an error transformer function as an alternative to the error object.

var x:Promise<string> = someRequest()
    .catchThrow(LowLevelError, e => new BusinessError(e))
    .then(res => res.stringField)  

[benjamingr]

It's perfectly possible to type catch well.

The reason people don't do it is because people hate checked exceptions and this is effectively the same thing. I talk about this here: http://stackoverflow.com/questions/29286018/typescript-typings-for-failure-reason-in-various-promises-implementations/29287864#29287864 although the types are somewhat wrong for didactic reasons.

Additionally we're never breaking .catch, it's in ES6

[benjamingr]

Also, JS is not Haskell :)

[Artazor]

@benjamingr thank you for your response!

I know about checked exceptions. And I've read you answer on StackOverflow. Unfortunately, catch itself can hardly be correctly typed. And checked exceptions are not related to this problem at all (!!!)

Nevertheless, to be more relevant to the real world in your type system there should be type unions (T1 + T2) , exclusions (T1 - T2) and exception monad/checked exceptions, that for the sake of simplicity we will replace with the special type (t ^ e) that means either success with t or failure with e. Promise<t,e> here will be denoted as (P t e)

Thus, we may try to start with the following type:

catch :: (P t e) -> (e' -> (s ^ e'')) -> P s (e - e' + e'')

But this still is not a correct type either.

The core problem for the catch typing is the conditional nature of the catch. It has an ability to conditionally change the type of the success value depending on the state of the source promise. If the promise is rejected then catch handler has a chance to be executed and change a result type. If the promise is fulfilled then entire catch section should be transparent and pass the result through itself along with its type. Voila! Contradiction! Depending on the runtime behavior we have different resulting types.

The only correct typing for catch is

catch :: (P t e) -> (e' -> (t ^ e'')) -> P t (e - e' + e'')

It means that to be semantically correct you should never change the type of the success in a catch handler.

Expressed in TypeScript it looks like:

declare class Promise<T> {
     catch(handler: (reason: any) => T|Promise<T>): Promise<T>
}

I'm working on Bluebird.d.ts for the v 3.0 (I'll publish it soon, I hope). And in fact I'd place such a constraint there. I suspect that all popular Promise library d.ts definitions are vulnerable to this semantic error. Because it is an inherent problem of the Promise.catch.

At the same time, people write correct programs with semantically incorrect tools.
And It would be nice to have a catch alternative that by definition does not change the type of the result.

That is why I've proposed the tapError. It would be a semantically correct version of the .catch().
I would let the .catch() alone for those who will take the risk to use it. Personally, I'll try to avoid using catch in my programs in favour of proposed #612 that is semantically correct.

Also, want to hear from @petkaantonov and @spion