Avoiding Swift Error & Swift Error Handling

“Error handling is the art of failing gracefully.”

Avoiding Swift Error

Guard Statements

Guard is an effective way to identify that is the condition is true or not: for example, if a value is > 0, or if a condition can be unwrapped. You can then execute a block of code if the check fails.

Guard was introduced in Swift 2.0 and is typically used for error handling through the call stack, where the error will eventually be handled. Guard statements allow early exit from a function or method, this makes it more clear which conditions need to be present for the rest of the processing logic to run.

guard let name = nameTextField.text else {
 show(“No name to submit”)
 return
}

With this change, there is no need for an else clause on a separate line and the failure case is more evident as it is now at the top of the initializer. Also, the “golden path” is the least indented. The “golden path” is the path of execution that happens when everything goes as expected, i.e. no error. Being least indented makes it easy to read.

Swift Error Handling

In Swift Programming Language there is a unique feature called Error Handling. It could be called as an exception in other different languages, though the syntaxes are not quite the same. Let us focus on how Swift errors work on the inside.

Semantics :

Let’s start with a quick refresher on how Swift errors work at the language level.

In Swift any function can be implemented with a throws keyword, which indicates that it can throw an error:

func getMyString() throws -> String { ...

To actually throw an error from such a function, use the throw keyword with a value that conforms to the Error protocol:

throw Error.NotFound

When calling a throws function, you must include the try keyword:

let string = try getMyString()

The try keyword doesn’t do anything but it is a required marker to indicate that the function might throw an error. The call must be in a context where throwing an error is allowed, either in a throws function or in a do block with a catch handler.

To write a catch handler, place the try call in a do block, and add a catch block:

do {
let string = try getMyString()
...
} catch {
print("Got an error: \(error)")
}

When an error is thrown, execution jumps to the catch block. The value that was thrown is available in error. You can get fancy with type checking and conditions and multiple catch clauses, but these are the basics.

Implementation

Let us see the example code with error handling

struct MyError: Error {
 var x: Int
 var y: Int
 var z: Int
 }

 func Thrower(x: Int, y: Int, z: Int) throws -> Int {
 throw MyError(x: x, y: y, z: z)
 }

 func Catcher(f: (Int, Int, Int) throws -> Int) {
 do {
 let x = try f(1, 2, 3)
 print("Received result : \(x)")
 } catch {
 print("Caught Error : \(error)")
 }
 }

Swift 3 works by essentially automating Objective-C’s NSError convention. The compiler inserts an extra hidden parameter which is essentially Error *, or NSError **. Throwing an error consists of writing the error object to the pointer passed in that parameter. The caller allocates some stack space and passes its address in that parameter. On return, it checks to see if that space now contains an error. If it does, it jumps to the catch block.

Swift 4 gets a little easier. The basic idea is the same, but instead of a normal extra parameter, a special register is reserved for the error return. Here is what the relevant assembly code in Thrower looks like:

 call imp___stubs__swift_allocError
mov qword [rdx], rbx
mov qword [rdx+8], r15
mov qword [rdx+0x10], r14
mov r12, rax

This calls into the Swift runtime to allocate a new error, fills it out with the relevant values, and then places the pointer into r12. It then returns to the caller. The relevant code in Catcher looks like this:

call r14
mov r15, rax
test r12, r12
je loc_100002cec

It makes the call, then checks if r12 contains anything. If it does, it jumps to the catch block. The technique on ARM64 is almost the same, with the x21 register serving as the error pointer. Internally, it looks a lot like returning a Result type, or otherwise returning some sort of error code. The throws function returns the thrown error to the caller in a special place. The caller checks that place for an error and jumps to the error handling code if so. The generated code looks similar to Objective-C code using an NSError ** parameter, and in fact, Swift 3’s version of it is identical.