Add 'isFaulted' property to BFTask - keep in line with Android

[marchy]

Hi there, can you please add an "isFaulted" property to BFTask on iOS?
The abstraction for the SDK should be as consistent as possible between Android and iOS - this one of the Bolts framework biggest benefits is that it allows cross-platform teams to write code that is architecturally identical across both the Objective-C and Java SDKs.

The API surface should be identical for all purposes, simply using language-specific mechanisms such as blocks in Obj-C, anonymous interfaces in Java to leverage each language's best native syntax for the API.

[bklimt]

Objective-C uses errors and exceptions differently, whereas Java just has the one concept of exceptions, so it's not really possible for them to be identical. isFaulted would have to mean something like "has an error or has an exception", but then you'd still need to check which kind to do anything reasonable. If you have a more specific use case that doesn't work right with the existing semantics, please share it with us.

[marchy]

Actually the whole point is that for most errors the presentation layer in the app (presumably the one invoking BFTask and handling the error callbacks) does not need to do anything different based on the kind of error. It simply needs to put the UI in an error state or clear out the UI async indicators. Special circumstances that require custom errors can be handled as you mention above, by checking whether it's an error or an exception. This is however the 5-10% case not the 90%.

In terms of presenting the actual error, common errors should be handled at a lower level anyways (ie: networking layer) and not performed by each caller. This is especially so on iOS where dialogs can be presented from any thread and don't need to be invoked using a live Activity Context as is the case on Android.

It would be easier for callers to check "if( task.isFaulted ) {..}" instead of checking "if( task.error != nil || task.exception != nil ) {..}" in every single place. Not only is it just bad API to require consumers to check whether two different properties are nil instead of having a semantic representation that achieves exactly what they want; but it is also error-prone and easily forgettable. A good API should guide you to what's needed and prevent you from screwing up.

I am confident this is a mis-design on your guys' part. Please reconsider and re-open the request.
The added benefit is it will also be more consistent with the Android library. :)