Do-catch alternative

David Owens' suggestion is to allow the omission of do {} and to allow catch to be attached directly to try, e.g.

try foo() catch {
    // Handle the error
}

Seems reasonable and less cluttered to me.

As a refinement, DO also suggests that this explicitly work in combination with guard:

guard let result = try foo() catch {
    // Handle the error - also, forced scope exit
}

This part I don't care for so much, because it conflates the handling of exceptions and nil returns. If foo() doesn't return an optional, then the guard adds nothing; you could just as well write

let result = try foo() catch {
   // Handle the error and exit scope
}

If foo() does return an optional, then it's just kind of a mess.

Like said by David:

func f() throws -> Int ?
guard let a = try f() else {
// this it the optional part
}
catch {
// this is the exception part
}

>> David Owens' suggestion is to allow the omission of do {} and to allow catch to be attached directly to try

While I don't see any reason to absolutely dislike this suggestion, a couple of problems occur to me:

1. The Obj-C source code construct that Swift error handling replaces is an 'if' that detects and handles the error (in combination with a nil or other "special" return value). This has always worked just fine for many years, but the longtime problem is that it's awfully verbose — not only does every failworthy call have to be weighed down by an if, but it also has to do so if its error handling just delegates to a calling method (i.e. it just returns nil to its caller).

The proposed construct partially brings back this problem, because it weighs down the individual calls again. (Yes, I know it was proposed as an alternative to the do … catch construct, not a replacement, but I think it's a step in the wrong direction.)

2. It seems clear to me that Swift is going to be forced — by popular demand — to provide some "bridge" between errors and optionals. That is, people seem to want to convert a "try" failure into an optional. (Converting an optional into an error is already possible — use 'throw'). When/if such concept-bridging syntax arrives, it probabaly removes most of the need for the proposed revision to try…catch syntax.

3. I also think the real problem is not the try…catch syntax itself, but the fact that an enclosing scope (do {…}) is manifestly inconvenient. I think that is real point where innovation is needed.

I don't have an actual suggestion about what innovation, but part of me wants to approach this like 'defer'. Rather than 'catch {…}' being a single choke-point for error detection, I wonder if there is a way for a series of catch blocks to be accumulated in the same way as defer blocks, and then executed as a whole at the end of some outer scope.

In other words, each 'try' could have its own "contribution" to the total catch behavior, without needing to centralized all of the error handling into a single block.

Ah, I hadn't read the comments on that thread - thanks.

I still find this somewhat messy, though if read carefully it's clear enough. I wouldn't want to change the language just to allow this particular construct - it's not really all that compelling.

I guess the more general question is why you shouldn't be able to apply a catch clause to any statement or block.

I completely agree with your third point. I don't really like the situation where (most) of my method is indented just to handle errors and provide a catch block.

While waiting for a better solution I would definitely like the omission-of-do syntax.