With Swift 2.0, you’ve probably been doing something like this to handle errors.

let foo = try somethingThatMaythrow

This calls a routine that potentially throws an error.

Somewhere in that calling chain, someone takes responsibility for catching errors, typically with do-catch. In this paradigm, the error is of interest primarily at the point of creation and the point of consumption. No other code needs deal with error conditions. Try is sufficient to pass the error handling along.

If you want to ignore the error chain, an exclamation point signals “success or die”. Any fail scenario creates a run-time crash.

let foo = try! somethingThatMayThrowIfItFailsCrashyCrashy

Now Beta 6 introduces try? (with a question mark). It returns an optional that wraps successful values and “catches” errors by returning nil.

guard let foo = try? somethingThatMayThrow else {
    handle error condition and leave scope}

if let foo = try? somethingThatMayThrow {}

In each of these example statements, the code conditionally binds a non-optional to foo, but you can assign foo directly and it’s assigned as an optional.

You can combine try? with ?? for fallback values but you must surround the try in parens at this point, as it took me several minutes to figure out:

In both uses, be aware that your error is discarded. Instead of:

if (!(value = [instance request:blah withError:&error])) 
{
    ...print error and return/die...
}

or:

if let value = instance.request(blah, error:&error) {
   ...success..
} else {
   ...print error and return/die...
}

or:

do {
    let value = try instance.request(blah)
} catch {... print error and return/die ...}

You’re working in a system where error conditions are transformed automatically into nil values.

So, what this gets you:

• Interoperability between Swift’s nullable optionals and its error system. For example, you can write throwing functions and consume them with if-let.
• A focus on success/failure where the calling context solely assumes responsibility for reporting error conditions. “I tried to do X and it failed somewhere.” Traditionally errors describe what went wrong. Now you describe what you were trying to do.

What you lose:

• Cocoa-style error handling. Any errors that are generated are eaten away and you won’t see them or know about them.
• Error source information such as the file / routine that generated the issue. All you know is that the calling chain failed somewhere but not why or how.
• Railway/Freight Train-style development, or as Jeremy Tregunna puts it, you lose “the either monad as inputs and outputs to code that can fail with left side being the error, right side being the value; binding these functions together with a binding operator that automatically propogates the first error through to the end of the chain”

When do you want to do this?

• When you’re focused more on success/failure than why things failed.
• When you’re working with well-tested API chains, so if you can’t construct a URL or save to file or whatever, you just want to note it and move on with your recovery code for a “did not succeed scenario”

This construct more or less steps back to using optional return values that signal success and failure, which we had moved beyond earlier this Summer. It’s time to rewrite a few manifestos.

In summary: ahoy ahoy, it’s a major paradigm shift. Developers take note.