continueOnError issue about bolts-swift HOT 5 OPEN

That's a great suggestion, but there is a weird scenario here, that I would love to discuss.

Taking into account that continueOnErrorWith doesn't run at all times, and only runs when the task is faulted - returning a non TResult from it is making an entire chain of tasks behave in a weird way, that is allowed by the type system at that point, but looks very weird and strange.

Let me give you an example:

let continueTask = task.continueOnSuccessWithTask { (settings: Settings) -> Task<String> in
    return self.updateSettingsTask()
}.task.continueOnErrorWith { (error: ErrorType) -> () in
    self.showError(error)
}

The type of continueTask is Task<Void> and not Task<Settings>, but if the entire chain succeeds and actual result of continueTask is of type Settings and not Void.

At the current moment continueOnErrorWith is built for error recovery, where it still doesn't violate the type system and the final result of the chain of tasks.

cc @grantland @richardjrossiii for discussion

from bolts-swift.

We have makeVoid() in Bolts-Android, and looks like it might be a great candidate for this scenario, where you won't have to create an empty continuation just to cast the task to Void result.

from bolts-swift.

I always thought of the error handler as being at the end of the chain, so I didn't consider that situation. I think that putting the error handler at the end of the chain is probably the way its used most of the time, but I agree that enforcing this restriction at the framework level isn't great.

I can also see the workaround I proposed suffers from the same issue. I don't see how the current implementation solves it though, without the makeVoid method. Is the error handler responsible for generating the correct result?

I like the idea of makeVoid(). How does it work though? Is the result of the previous task in the chain passed on to the error handlers continuations? The only problem with that is, we don't know which task in the chain failed, and a result might not have been created yet. The only way I see it working is if the error handler generates the result. Am I right in thinking this way?

from bolts-swift.

I still feel like my proposed solution provides the flexibility to be able to switch to a void task, or return a result of the same type as the previous task in the chain. The swift compiler is smart enough to pick up any type mismatches. But this way the developer will have the flexibility to decide which way to use it.

Or Is the explicit makeVoid call to opt in to the functionality preferred over the implicit switch? The more I think about it, the more it seems like its just a matter of style preference, explicit vs implicit

from bolts-swift.

Hi @nlutsenko , I think makeVoid()'s counter part in swift is emptyTask(). But it is internal function. How we can make youse of internal functions in our own modules.

from bolts-swift.