The Power of Guard

Here’s a guard statement with many different kinds of features by Benedikt Terhechte:

guard let messageids = overview.headers["message-id"],
    messageid = messageids.first,
    case .MessageId(_, let msgid) = messageid
    where msgid == self.originalMessageID
    else { return print("Unknown Message-ID:", overview) }

I love guard statements. It helps make code much more readable and keep methods un-intended.

I feel less amorous about guard-case and if-case matching, though:

if case .Fruit = foodType { ... }

This reads an awful lot like Yoda conditions where you place the constant portion on the left side. This isn’t even a typical boolean test (which would use the equality operator ==) but a failable assignment (=). I can force myself to read and write it this way, but it always feels backward to me. It took me quite a while to memorize this, which I found surprising, as it was comparatively easy to learn Swift in the first place.

Apart from the guard-case portion, the example contains your standard guard-let unwrapping. The else clause is special though, and I didn’t know this would work:

guard someCondition else { return print("a problem") }

When the function is of return type Void, you can return a call to another void function. This is shorter than splitting these two instructions on two lines, but it’s too clever for every reader to understand. print("a problem"); return is just as compact, as Terhechte points out.

Be Cautious with Try-Catch for error handling in Swift 2.0

Teaser image

Throwing exceptions and being able to catch them is awesome news. Then there are cases which can be handled with try-catch technically, but shouldn’t. Think about this: in what cases could you make use of that? And what are the consequences for your work? For example, Erica Sadun points out that accessing array indexes out of bounds as a subscript will still crash the app since you can’t catch that kind of exception (yet).

Continue reading …

Going Beyond Guard Clauses in Swift

Teaser image

Erica Sadun brought up a topic which is bugging me for some time already. It’s how Swift encourages you to handle optionals. It’s related to handling exceptions, which I covered earlier. Either you use if-let to unwrap them implicitly and do all the stuff inside the nested code block, or you end up with code which is a lot wordier than I’d like it to be.

Continue reading …

Functional Error Handling in Swift Without Exceptions

In Swift, there’s no exception handling or throwing. If you can’t use exceptions for control flow like you would in Java, what else are you going to do if you (a) write library code which executes a failing subroutine, and (b) you find unwrapping optionals too cumbersome? I played with the thought of keeping Swift code clean, avoiding the use of optionals, while maintaining their intent to communicate failing operations.

Continue reading …