Enum error swift

Representing and Throwing Errors¶

In Swift, errors are represented by values of types that conform to the Error protocol. This empty protocol indicates that a type can be used for error handling.

Swift enumerations are particularly well suited to modeling a group of related error conditions, with associated values allowing for additional information about the nature of an error to be communicated. For example, here’s how you might represent the error conditions of operating a vending machine inside a game:

Throwing an error lets you indicate that something unexpected happened and the normal flow of execution can’t continue. You use a throw statement to throw an error. For example, the following code throws an error to indicate that five additional coins are needed by the vending machine:

Handling Errors¶

When an error is thrown, some surrounding piece of code must be responsible for handling the error—for example, by correcting the problem, trying an alternative approach, or informing the user of the failure.

There are four ways to handle errors in Swift. You can propagate the error from a function to the code that calls that function, handle the error using a do—catch statement, handle the error as an optional value, or assert that the error will not occur. Each approach is described in a section below.

When a function throws an error, it changes the flow of your program, so it’s important that you can quickly identify places in your code that can throw errors. To identify these places in your code, write the try keyword—or the try? or try! variation—before a piece of code that calls a function, method, or initializer that can throw an error. These keywords are described in the sections below.

Specifying Cleanup Actions¶

You use a defer statement to execute a set of statements just before code execution leaves the current block of code. This statement lets you do any necessary cleanup that should be performed regardless of how execution leaves the current block of code—whether it leaves because an error was thrown or because of a statement such as return or break. For example, you can use a defer statement to ensure that file descriptors are closed and manually allocated memory is freed.

A defer statement defers execution until the current scope is exited. This statement consists of the defer keyword and the statements to be executed later. The deferred statements may not contain any code that would transfer control out of the statements, such as a break or a return statement, or by throwing an error. Deferred actions are executed in the reverse of the order that they’re written in your source code. That is, the code in the first defer statement executes last, the code in the second defer statement executes second to last, and so on. The last defer statement in source code order executes first.

The above example uses a defer statement to ensure that the open(_:) function has a corresponding call to close(_:).

Brad Larson of
Sunset Lake Software wrote a
blog post
called “Why we’re rewriting out robotics software in Swift.” The article is a
worthwhile read, and explains that an audit of their Objective-C code history
revealed that approximately 40% of the shipped bugs would have been prevented by
using Swift. Which is really interesting.

I would like to focus on a different part of the article, however. It’s actually more of an aside
in the article itself, but it was something that really stood out to me: the
use of enums instead of NSError in Swift. Brad goes into more detail on the
subject in a mailing list post.
After having played with it myself, I think using enums for errors is a really
big win, and I intend to use the pattern in my own Swift code going forward.

What’s Painful About NSError

NSError is used in code built on the Foundation framework for recoverable error
situations. By merely receiving an NSError object, you know something went
wrong, and you can inspect the object to learn more detail about what happened.
A good writeup on NSError can be found at NSHipster.

Unfortunately, constructing and inspecting NSErrors can be cumbersome. To create
an NSError, you need to specify a domain and a code. The domain should be a
reverse DNS-style string, like “com.company.app”. The code needs to be an
integer that’s unique within the error domain. The domain and code tend to be of
limited usefulness when using NSErrors later, but you need to supply them when
creating NSError objects anyway.

The more-often useful information in an NSError lives in its userInfo
dictionary. You provide values for a few system-defined keys like
NSLocalizedDescriptionKey, and you can attach any additional objects you wish
to the same dictionary. I often need to refer to documentation to remember
NSLocalizedDescriptionKey, and attaching extra information to the dictionary
requires you to keep track of the keys you use in order to consume them later.
Picking apart an NSError very frequently involves trips to a header file or
framework documentation.

Using Swift enums nicely addresses these complaints.

A Swifty Enum Error

So what does an enum error look like? Here’s an example of a hypothetical error
type for interacting with an API server.

enum APIError {
    case NoInternet
    case HTTPError(statusCode: Int)
    case ServerError(message: String)
}

A function which can produce an error could look like this.

typealias APICallback = (data: NSData?, error: APIError?) -> Void
func makeAPICall(callback: APICallback) -> Void {
    // Success
    callback(data: NSData(), error: nil)
    
    // There was no internet connection
    callback(data: nil, error: .NoInternet)
    
    // There was an HTTP error code
    callback(data: nil, error: .HTTPError(statusCode: 404))
    
    // The server rejected the call
    callback(data: nil, error: .ServerError(message: errorMessage))
}

Creating errors becomes easy, clear, and descriptive. It’s even
statically-typed, so the compiler will require you to construct the error
correctly.

Consuming errors is simple, as well. You could use a switch statement to handle
some—or all—cases.

switch(error) {
case .NoInternet:
    println("You should get a better ISP")
case .ServerError(let message):
    println("The server responded with message: (message)")
default:
    // Handle other error cases in a general way
}

Often you just want a textual description of the error. You might want to put
the text into an alert view, or you might want to log out the error description
while debugging. This can be handled by having your error type implement
the Printable protocol.

enum APIError: Printable {
    case NoInternet
    case HTTPError(statusCode: Int)
    case ServerError(message: String)
    
    var description: String {
        switch self {
        case .NoInternet:
            return "There is no internet connection."
        case .HTTPError(let statusCode):
            return "The call failed with HTTP code (statusCode)."
        case .ServerError(let message):
            return "The server responded with message "(message)"."
        }
    }
}

Printing the error then becomes as simple as this.

println(error)

In my time with this style of error, I believe they are far easier to construct
and consume than NSError, so I quite like them.

What About Objective-C Compatibility?

Unfortunately, Swift enums can’t export to Objective-C. So what if you want to
use these awesome enum errors in Swift, but still need your code to be
consumable from Objective-C? In that case, you need to provide a way to
translate the enum error to an NSError object, and then export the NSError
object to Objective-C.

You can pull this off by adding a foundationError property to your enum error.

enum APIError: Printable {
    case NoInternet
    case HTTPError(statusCode: Int)
    case ServerError(message: String)
    
    private var domain: String {
        return "com.company.app"
    }
    
    private var errorCode: Int {
        switch self {
        case .NoInternet:
            return 100
        case .HTTPError(let statusCode):
            return 101
        case .ServerError(let message):
            return 102
        }
    }
    
    var description: String {
        switch self {
        case .NoInternet:
            return "There is no internet connection."
        case .HTTPError(let statusCode):
            return "The call failed with HTTP code (statusCode)."
        case .ServerError(let message):
            return "The server responded with message "(message)"."
        }
    }
    
    var foundationError: NSError {
        return NSError(domain: domain, code: errorCode, userInfo: [
            NSLocalizedDescriptionKey : description
        ])
    }
}

Then, in code that can return an error, you must provide overloads that return
an NSError.

func makeCall() -> APIError? {
    return .NoInternet
}

func makeCall() -> NSError? {
    return makeCall()?.foundationError
}

The NSError-returning overload will be the only version made available to
Objective-C, so it’ll be as if your enum error code doesn’t even exist there.

Since both overloads will be visible from Swift, however, you’ll need to be
explicit about the overload you call, instead of letting Swift infer the type.

let error: APIError? = makeCall()

It’s not the best solution, since you have to add extra code to handle codes
and domains to the error enum, and you have to use explicit typing when calling
from Swift, but it still more or less gets you the best of both worlds.

Of course, the better long-term solution to this problem is to stop using
Objective-C altogether and just use Swift full-time

Обработка ошибок

Обработка ошибок — это процесс реагирования на возникновение ошибок и восстановление после появления ошибок в программе. Swift предоставляет первоклассную поддержку при генерации, вылавливании и переносе ошибок, устранении ошибок во время выполнения программы.

Некоторые операции не всегда гарантируют полное выполнение или конечный результат. Опционалы используются для обозначения отсутствия значения, но когда случается сбой, важно понять, что вызвало сбой, для того, чтобы соответствующим образом изменить код.

В качестве примера, рассмотрим задачу считывания и обработки данных из файла на диске. Задача может провалиться по нескольким причинам, в том числе: файл не существует по указанному пути, или файл не имеет разрешение на чтение, или файл не закодирован в необходимом формате. Отличительные особенности этих различных ситуаций позволяют программе решать некоторые ошибки самостоятельно и сообщать пользователю какие ошибки она не может решить сама.

Отображение и генерация ошибок

В Swift ошибки отображаются значениями типов, которые соответствуют протоколу Error. Этот пустой протокол является индикатором того, что это перечисление может быть использовано для обработки ошибок.

Перечисления в Swift особенно хорошо подходят для группировки схожих между собой условий возникновения ошибок и соответствующих им значений, что позволяет получить дополнительную информацию о природе самой ошибки. Например, вот как отображаются условия ошибки работы торгового автомата внутри игры:

enum VendingMachineError: Error {
    case invalidSelection
    case insufficientFunds(coinsNeeded: Int)
    case outOfStock
}

Генерация ошибки позволяет указать, что произошло что-то неожиданное и обычное выполнение программы не может продолжаться. Для того чтобы «сгенерировать» ошибку, вы используете инструкцию throw. Например, следующий код генерирует ошибку, указывая, что пять дополнительных монет нужны торговому автомату:

throw VendingMachineError.insufficientFunds(coinsNeeded: 5)

Обработка ошибок

Когда генерируется ошибка, то фрагмент кода, окружающий ошибку, должен быть ответственным за ее обработку: например, он должен исправить ее, или испробовать альтернативный подход, или просто информировать пользователя о неудачном исполнении кода.

В Swift существует четыре способа обработки ошибок. Вы можете передать (propagate) ошибку из функции в код, который вызывает саму эту функцию, обработать ошибку, используя инструкцию do-catch, обработать ошибку, как значение опционала, или можно поставить утверждение, что ошибка в данном случае исключена. Каждый вариант будет рассмотрен далее.

Когда функция генерирует ошибку, последовательность выполнения вашей программы меняется, поэтому важно сразу обнаружить место в коде, которое может генерировать ошибки. Для того, чтобы выяснить где именно это происходит, напишите ключевое слово try — или варианты try? или try!— до куска кода, вызывающего функцию, метод или инициализатор, который может генерировать ошибку. Эти ключевые слова описываются в следующем параграфе.

Передача ошибки с помощью генерирующей функции

Чтобы указать, что функция, метод или инициализатор могут генерировать ошибку, вам нужно написать ключевое слово throws в реализации функции после ее параметров. Функция, отмеченная throws называется генерирующей функцией. Если у функции установлен возвращаемый тип, то вы пишете ключевое слово throws перед стрелкой возврата (->).

func canThrowErrors() throws -> String
func cannotThrowErrors() -> String

Генерирующая функция передает ошибки, которые возникают внутри нее в область вызова этой функции.

В приведенном ниже примере VendingMachine класс имеет vend(itemNamed: ) метод, который генерирует соответствующую VendingMachineError, если запрошенный элемент недоступен, его нет в наличии, или имеет стоимость, превышающую текущий депозит:

struct Item {
    var price: Int
    var count: Int
}
 
class VendingMachine {
    var inventory = [
        "Candy Bar": Item(price: 12, count: 7),
        "Chips": Item(price: 10, count: 4),
        "Pretzels": Item(price: 7, count: 11)
    ]
    var coinsDeposited = 0
    
    func vend(itemNamed name: String) throws {
        guard let item = inventory[name] else {
            throw VendingMachineError.invalidSelection
        }
        
        guard item.count > 0 else {
            throw VendingMachineError.outOfStock
        }
        
        guard item.price <= coinsDeposited else {
            throw VendingMachineError.insufficientFunds(coinsNeeded: item.price - coinsDeposited)
        }
        
        coinsDeposited -= item.price
        
        var newItem = item
        newItem.count -= 1
        inventory[name] = newItem
        
        print("Dispensing (name)")
    }
}

Реализация vend(itemNamed: ) метода использует оператор guard для раннего выхода из метода и генерации соответствующих ошибок, если какое-либо требование для приобретения закуски не будет выполнено. Потому что инструкция throw мгновенно изменяет управление программой, и выбранная позиция будет куплена, только если все эти требования будут выполнены.

Поскольку vend(itemNamed: ) метод передает все ошибки, которые он генерирует, вызывающему его коду, то они должны быть обработаны напрямую, используя оператор do-catch, try? или try!, или должны быть переданы дальше. Например, buyFavoriteSnack(person:vendingMachine: ) в примере ниже — это тоже генерирующая функция, и любые ошибки, которые генерирует метод vend(itemNamed: ), будут переноситься до точки, где будет вызываться функция buyFavoriteSnack(person:vendingMachine: ).

let favoriteSnacks = [
    "Alice": "Chips",
    "Bob": "Licorice",
    "Eve": "Pretzels"
]
func buyFavoriteSnack(person: String, vendingMachine: VendingMachine) throws {
    let snackName = favoriteSnacks[person] ?? "Candy Bar"
    try vendingMachine.vend(itemNamed: snackName)
}

В этом примере, функция buyFavoriteSnack(person:vendingMachine: ) подбирает любимые закуски данного человека и пытается их купить, вызывая vend(itemNamed: ) метод. Поскольку метод vend(itemNamed: ) может сгенерировать ошибку, он вызывается с ключевым словом try перед ним.

Генерирующие ошибку инициализаторы могут распространять ошибки таким же образом, как генерирующие ошибку функции. Например, инициализатор структуры PurchasedSnack в списке ниже вызывает генерирующую ошибку функции как часть процесса инициализации, и он обрабатывает любые ошибки, с которыми сталкивается, путем распространения их до вызывающего его объекта.

struct PurchasedSnack {
    let name: String
    init(name: String, vendingMachine: VendingMachine) throws {
        try vendingMachine.vend(itemNamed: name)
        self.name = name
    }
}

Обработка ошибок с использованием do-catch

Используйте инструкцию do-catch для обработки ошибок, запуская блок кода. Если выдается ошибка в коде условия do, она соотносится с условием catch для определения того, кто именно сможет обработать ошибку.

Вот общий вид условия do-catch:

do {
    try выражение
    выражение
} catch шаблон 1 {
    выражение
} catch шаблон 2  where условие {
    выражение
} catch шаблон 3, шаблон 4 where условие {
    выражение
} catch {
    выражение
}

Вы пишете шаблон после ключевого слова catch, чтобы указать какие ошибки могут обрабатываться данным пунктом этого обработчика. Если условие catch не имеет своего шаблона, то оно подходит под любые ошибки и связывает ошибки к локальной константе error. Более подробно о соответствии шаблону см. Шаблоны.

Например, следующий код обрабатывает все три случая в перечислении VendingMachineError, но все другие ошибки должны быть обработаны окружающей областью:

var vendingMachine = VendingMachine()
vendingMachine.coinsDeposited = 8
do {
    try buyFavoriteSnack(person: "Alice", vendingMachine: vendingMachine)
} catch VendingMachineError.invalidSelection {
    print("Ошибка выбора.")
} catch VendingMachineError.outOfStock {
    print("Нет в наличии.")
} catch VendingMachineError.insufficientFunds(let coinsNeeded) {
    print("Недостаточно средств. Пожалуйста вставьте еще (coinsNeeded) монетки.")
} catch {
    print("Неожиданная ошибка: (error).")
}
// Выведет "Недостаточно средств. Пожалуйста вставьте еще 2 монетки.

В приведенном выше примере, buyFavoriteSnack(person:vendingMachine: ) функция вызывается в выражении try, потому что она может сгенерировать ошибку. Если генерируется ошибка, выполнение немедленно переносится в условия catch, которые принимают решение о продолжении передачи ошибки. Если ошибка не генерируется, остальные операторы do выполняются.

В условии catch не нужно обрабатывать все возможные ошибки, которые может вызвать код в условии do. Если ни одно из условий catch не обрабатывает ошибку, ошибка распространяется на окружающую область. Однако распространяемая ошибка должна обрабатываться некоторой внешней областью. В функции nonthrowing условие включения do-catch должно обрабатывать ошибку. В функции throwing либо включающая условие do-catch, либо вызывающая сторона должна обрабатывать ошибку. Если ошибка распространяется на область верхнего уровня без обработки, вы получите ошибку исполнения.

Например, приведенный ниже пример можно записать так, чтобы любая ошибка, которая не является VendingMachineError, вместо этого захватывалась вызывающей функцией:

func nourish(with item: String) throws {
    do {
        try vendingMachine.vend(itemNamed: item)
    } catch is VendingMachineError {
        print("Некорректный вывод, нет в наличии или недостаточно денег.")
    }
}

do {
    try nourish(with: "Beet-Flavored Chips")
} catch {
    print("Unexpected non-vending-machine-related error: (error)")
}
// Выведет "Некорректный вывод, нет в наличии или недостаточно денег."

В nourish(with: ), если vend(itemNamed : ) выдает ошибку, которая является одним из кейсов перечисления VendingMachineError, nourish(with: ) обрабатывает ошибку, печатая сообщение. В противном случае, nourish(with: ) распространяет ошибку на свое место вызова. Ошибка затем попадает в общее условие catch.

Преобразование ошибок в опциональные значения

Вы можете использовать try? для обработки ошибки, преобразовав ее в опциональное значение. Если ошибка генерируется при условии try?, то значение выражения вычисляется как nil. Например, в следующем коде x и y имеют одинаковые значения и поведение:

func someThrowingFunction() throws -> Int {
    // ...
}
 
let x = try? someThrowingFunction()
 
let y: Int?
do {
    y = try someThrowingFunction()
} catch {
    y = nil
}

Если someThrowingFunction() генерирует ошибку, значение x и y равно nil. В противном случае значение x и y — это возвращаемое значение функции. Обратите внимание, что x и y являются опциональными, независимо от того какой тип возвращает функция someThrowingFunction().

Использование try? позволяет написать краткий код обработки ошибок, если вы хотите обрабатывать все ошибки таким же образом. Например, следующий код использует несколько попыток для извлечения данных или возвращает nil, если попытки неудачные.

func fetchData() -> Data? {
    if let data = try? fetchDataFromDisk() { return data }
    if let data = try? fetchDataFromServer() { return data }
    return nil
}

Запрет на передачу ошибок

Иногда вы знаете, что функции throw или методы не сгенерируют ошибку во время исполнения. В этих случаях, вы можете написать try! перед выражением для запрета передачи ошибки и завернуть вызов в утверждение того, что ошибка точно не будет сгенерирована. Если ошибка на самом деле сгенерирована, вы получите сообщение об ошибке исполнения.

Например, следующий код использует loadImage(atPath: ) функцию, которая загружает ресурс изображения по заданному пути или генерирует ошибку, если изображение не может быть загружено. В этом случае, поскольку изображение идет вместе с приложением, сообщение об ошибке не будет сгенерировано во время выполнения, поэтому целесообразно отключить передачу ошибки.

let photo = try! loadImage(atPath: "./Resources/John Appleseed.jpg")

Установка действий по очистке (Cleanup)

Вы используете оператор defer для выполнения набора инструкций перед тем как исполнение кода оставит текущий блок. Это позволяет сделать любую необходимую очистку, которая должна быть выполнена, независимо от того, как именно это произойдет — либо он покинет из-за сгенерированной ошибки или из-за оператора, такого как break или return. Например, вы можете использовать defer, чтобы удостовериться, что файл дескрипторов закрыт и выделенная память вручную освобождена.

Оператор defer откладывает выполнение, пока не происходит выход из текущей области. Этот оператор состоит из ключевого слова defer и выражений, которые должны быть выполнены позже. Отложенные выражения могут не содержать кода, изменяющего контроль исполнения изнутри наружу, при помощи таких операторов как break или return, или просто генерирующего ошибку. Отложенные действия выполняются в обратном порядке, как они указаны, то есть, код в первом операторе defer выполняется после кода второго, и так далее.

func processFile(filename: String) throws {
    if exists(filename) {
        let file = open(filename)
        defer {
            close(file)
        }
        while let line = try file.readline() {
            // работаем с файлом.
        }
        // close(file) вызывается здесь, в конце зоны видимости.
    }
}

Приведенный выше пример использует оператор defer, чтобы удостовериться, что функция open(_: ) имеет соответствующий вызов и для close(_: ).

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

An error (exception) is an unexpected event that occurs during program execution. For example,

var numerator = 10
var denominator = 0

// try to divide a number by 0
var result = numerator / denominator // error code

Here, we are trying to divide a number. So this type of error causes the abnormal termination of the program.

Steps For Error Handling in Swift

1. Create an enum that represents the types of errors.
2. Create a throwing function using the throws keyword.
3. Call the function using the try keyword.
4. Wrap the code with try in the do {...} block and add the catch {...} block to handle all errors.

1. Create enum of Errors

In Swift, we need to create an enum that represents the type of errors we may encounter while writing the program.

The enum we create must conform to the Error protocol so that we can throw an error value inside the function.

Let’s see an example,

enum DivisionError: Error {
  case dividedByZero
}

Here, we have created an enum named DivisionError with the value dividedByZero.

Since DivisionError conforms to the Error protocol, we’ll now be able to throw the error value of the enum.

2. Create a Throwing Function

In order to throw errors, we need to create a throwing function using the throws keyword.

Then we use the throw statement inside the function to throw a particular error represented by the enum. For example,

// create throwing function using throws keyword
func division(numerator: Int, denominator: Int) throws {

// throw error if divide by 0
  if denominator == 0 {
    throw DivisionError.dividedByZero
  }
  ...     
}

Here, we have created a throwing function named division() using the throws keyword. The function throws the dividedByZero value of the DivisionError enum if denominator == 0

Now, based on the value passed during the function call, the function throws an error if the error condition is met.

Note: The throw keyword has the same effect as the return keyword. return returns some value from the function, whereas throw returns error value from the function.

3. Function Call Using try Keyword

In Swift, we use the try keyword while calling the throwing function. It indicates that a function can throw an error. For example,

// call throwing function using try keyword
try division(numerator: 10, denominator: 0)

However, the error handling process is still incomplete. If we run the program now, we’ll get an error message: An error was thrown and was not caught

So, in order to catch the thrown error, we use the do-catch statement.

4. Handling Errors Using do-catch Statement

In Swift, we wrap the try code in the do block and add the catch block to handle all errors. For example,

do {
  try division(numerator: 10, denominator: 0)
  ...
}

catch DivisionError.dividedByZero {
  // statement
}

Here, we have called the throwing function division() from within the do block and attached the catch block to catch the error in case the function throws one.

The above catch block is executed based on the enum value of DivisionError.

This is the final step to handle possible errors that may occur in our program.

Example: Swift Error Handling

// create an enum with error values
enum DivisionError: Error {

  case dividedByZero
}

// create a throwing function using throws keyword
func division(numerator: Int, denominator: Int) throws {

  // throw error if divide by 0
  if denominator == 0 {
    throw DivisionError.dividedByZero
  }
    
  else {
    let result = numerator / denominator
    print(result)
  }
}

// call throwing function from do block
do {
  try division(numerator: 10, denominator: 0)
  print("Valid Division")
}

// catch error if function throws an error
catch DivisionError.dividedByZero {
  print("Error: Denominator cannot be 0")
}

Output

Error: Denominator cannot be 0

In the above example,

• DivisionError is an enum
• division() is a throwing function
• the do-catch statement handles the error

We have used try to pass values to the throwing function

try division(numerator: 10, denominator: 0)

to check if the passed values meet the error condition or not.

If the error condition is

• met — the throwing function throws the error, which is caught by the catch block.
• not met — the else statement inside throwing function and print statement inside the do block are executed.

Disable Error Handling

In Swift, sometimes we can be confident that the throwing function won’t throw an error at runtime.

In that case, we can write try! during the function call to disable the error handling. For example,

enum DivisionError: Error {
  
  case dividedByZero
}

func division(numerator: Int, denominator: Int) throws {
  if denominator == 0 {
    throw DivisionError.dividedByZero
  }
    
  else {
    let result = numerator / denominator
    print("Result:", result)
  }
}

// disable error handling
try! division(numerator: 10, denominator: 5)

Output

Result: 2

In the above example, we have used try! during the function call to disable the error handling.

try! division(numerator: 10, denominator: 5)

Here, since we have assigned value 5 to denominator, we know that the program will not throw an error. So we have disabled the error handling.

Also notice that when we use try!, we don’t need to use the do-catch statement.

Note: If we use try! and there is an error, our app will simply crash.

Causes of Error in Swift

An error can occur for many reasons. Some of them are:

• Invalid user input
• Device failure
• Loss of network connection
• Physical limitations (out of disk memory)
• Code errors
• Opening an unavailable file

Since the errors abnormally terminate the execution of a program, it is important to handle these kinds of errors.

# Error handling basics

Functions in Swift may return values, throw errors (opens new window), or both:

Any value which conforms to the ErrorType protocol (opens new window) (including NSError objects) can be thrown as an error. Enumerations (opens new window) provide a convenient way to define custom errors:

An error indicates a non-fatal failure during program execution, and is handled with the specialized control-flow constructs do/catch, throw, and try.

Errors can be caught with do/catch:

Any function which can throw an error must be called using try, try?, or try!:

# Catching different error types

Let’s create our own error type for this example.

The Do-Catch syntax allows to catch a thrown error, and automatically creates a constant named error available in the catch block:

You can also declare a variable yourself:

It’s also possible to chain different catch statements. This is convenient if several types of errors can be thrown in the Do block.

Here the Do-Catch will first attempt to cast the error as a CustomError, then as an NSError if the custom type was not matched.

In Swift 3, no need to explicitly downcast to NSError.

# Catch and Switch Pattern for Explicit Error Handling

In the client class:

# Disabling Error Propagation

The creators of Swift have put a lot of attention into making the language expressive and error handling is exactly that, expressive. If you try to invoke a function that can throw an error, the function call needs to be preceded by the try keyword. The try keyword isn’t magical. All it does, is make the developer aware of the throwing ability of the function.

For example, the following code uses a loadImage(atPath:) function, which loads the image resource at a given path or throws an error if the image can’t be loaded. In this case, because the image is shipped with the application, no error will be thrown at runtime, so it is appropriate to disable error propagation.

# Create custom Error with localized description

Create enum of custom errors

Create extension of RegistrationError to handle the Localized description.

Handle error:

For more information about errors, see The Swift Programming Language (opens new window).