Add `catch`

[robb]

To quickly recap the previous discussion:

I asked if there should be a catch or recoverWith method along the lines of:

extension Result {
    func catch(transform: NSError -> Result<T>) -> Result<T> {
        switch self {
            case Success(let value): return .Success(value)
            case Failure(let error): return transform(error)
        }
    }
}

@rnapier responded thusly:

catch looks very similar to recoverWith() that I've been playing with based on recover() from Scala Futures.

The problem I ran into it in this formulation is that it can be be overly aggressive. Consider:

   let x = something()
     .flatMap(more)
     .flatMap(commonFailer)
     .catch(recoveryFunc)
     .flatMap(evenMore)

The problem I kept bumping into is that I meant recoveryFunc to apply to commonFailer, but it necessarily applies to everything up to that point. I found that injected surprising bugs because errors from something() were ignored in a spooky-action-at-a-distance kind of way.

I've been exploring a tighter binding like this:

let x = something()
  .flatMap(more)
  .recoverWith(recoveryFunc, commonFailer)
  .flatMap(evenMore)

As a real-world example from my code (in this iteration I was calling it rescueWith, which might also be a fine name):

  return apiResultP(url) { $0
    |> asJSON          >>== asJSONDictionary
    >>== forKey("query") >>== asJSONDictionary
    >>== forKey("pages") >>== asJSONDictionary
    >>== forKey(toString(page.identifier)) >>== asJSONDictionary
    >>== rescueWith([], { forKey("images") >>== asJSONArray })

    >>== forEach { $0 |> asJSONDictionary
                   >>== forKey("title") >>== asString
                   <**> { (page, $0) }
                 }
  }
}

My old catch-style code quietly ignored network errors, which I didn't realize was happening until I built more negative tests.

[robb]

Couldn't you rewrite

let x = something()
    .flatMap(more)
    .flatMap(commonFailer)
    .catch(recoveryFunc)
    .flatMap(evenMore)

into something like

let x = something()
    .flatMap(more)
    .flatMap { 
        success($0)
            .flatMap(commonFailer)
            .catch(recoveryFunc)
    }
    .flatMap(evenMore)

though?

[rnapier]

You can write it that way, but the mistake is easy to make (or at least I
can say I made it, and had trouble figuring it out in a complex
expression). And the work-around idiom is non-obvious. At the point you
include success($0), it's not clear why you're doing it. I worry that
maintainers can easily fall into injecting errors by putting a catch in the
wrong place.

If you compare to try/catch in most languages, "try" is required and adds a
block around the thing you want to recover from. You don't just inject
"catch" at the point that you want all previous errors to be dealt with.

I could see an actual try/catch syntax, however, that would make the intent
clearer. Maybe something like (may not compile):

let x = something()
    .flatMap(more)
    .try( { $0.flatMap(commonFailer) },
          catch: recoveryFunc)
    .flatMap(evenMore)

(Not sure if we can get away without the success() in there.) I don't love
this sytnax though. I think the .recoverWith() is clearer.

Of course with a little more complexity, creating a Try struct, this syntax
is possible, preserving type-safety and being more difficult to get wrong:

let x = something()
    .flatMap(more)
    .try(commonFailer)
    .catch(recoveryFunc)
    .flatMap(evenMore)

Then Result.try() would return a Try, and Try.catch() would return a
Result. I'm not sure if that's too complex, though. Try would need to be
something like:

enum Try <T,E> {
    case .Success(Box(T))
    case .Thrown(Box(E)) // error returned by the try (so should be caught)
    case .Error(Box(E)) // error that came into the try (so should not be
caught)
}