Swi! 2 Error Handling 

No content

No content

public struct Account { public enum Error : ErrorType { case TransactionExceedsFunds case NonPositiveTransactionNotAllowed(amount: Int) } var fund: Int public mutating func withdraw(amount: Int) throws { guard amount < fund else { throw Error.TransactionExceedsFunds } guard amount > 0 else { throw Error.NonPositiveTransactionNotAllowed(amount: amount) } fund -= amount } } 

enum Error : ErrorType { case NoArgumentGiven case ArgumentIsNotAnInteger } var arguments = Process.arguments // Remove the executable name. assert(arguments.count >= 1) arguments.removeAtIndex(0) guard let firstArg = arguments.first else { throw Error.NoArgumentGiven } guard let amount = Int(firstArg) else { throw Error.ArgumentIsNotAnInteger } 

let dict = NSMutableDictionary(contentsOfFile: "account.plist") ?? NSMutableDictionary() let fund = dict["fund"] as? Int ?? 100 var account = Account(fund: fund) do { try account.withdraw(amount) dict["fund"] = account.fund dict.writeToFile("account.plist", atomically: true) } catch Account.Error.NonPositiveTransactionNotAllowed(let amount) { print("Amount (\(amount)) must be positive.") } catch Account.Error.TransactionExceedsFunds { print("Amount exceeds account balance (\(account.fund)).") } catch { print("An unexpected error <\(error)> occured.") } 

Throwing, NonThrowing and ReThrowing 

Take a Look into the Book 

A throwing method can’t override a nonthrowing method, and a throwing method can’t satisfy a protocol requirement for a nonthrowing method. … 

… That said, a nonthrowing method can override a throwing method, and a nonthrowing method can satisfy a protocol requirement for a throwing. 

Non Throwing ⊂ Throwing 

Model protocol ThrowingFunction { typealias ParameterType typealias ReturnType func call(parameter: ParameterType) throws -> ReturnType } protocol NonThrowingFunction : ThrowingFunction { func call(parameter: ParameterType) -> ReturnType } 

How does rethrows fits in? 

rethrows is the shapeshifter 

as throwing let str: String var x = 0 do { try parse(str) { (char) in if char == "+" { x += 1 } else { throw Error.UnexpectedChar } } } catch error { print("Error occured while parsing: \(error)") } 

as nonthrowing var x = 0 parse(str) { (char) in if char == "+" { x += 1 } } 

Limits You can just try the closure. Trying something else is forbidden. ! 

ErrorType demystified 

// from SwiftExP public enum Error : ErrorType { case UnexpectedEOS case IllegalNumberFormat(numberString: String) case IllegalEscapeSequence(escapeSequence: String) case NonTerminatedList case NonTerminatedQuotedString case IllegalHexCharacter(char: Character) } 

protocol ErrorType { } 

(lldb) type lookup ErrorType protocol ErrorType { var _domain: Swift.String { get } var _code: Swift.Int { get } } 

Implements some Protocols by Default · Hashable · Equatable 

struct Error : ErrorType { // Not necessary since Xcode 7b5, // but let you avoid to write underscores. var code: Int var domain: String var _code: Int { return code } var _domain: String { return domain } } 

Swift's Error Throwing under the hood 

Swift's Error Throwing under the hood · Breaks the control flow · Syntax sugar around NSError pointers · Isn't as expensive as Objective-C exceptions 

class Object { } enum Error : ErrorType { case HelloWorld } func foo(x: Int) throws -> Object { let obj = Object() if x == 0 { throw Error.HelloWorld } return obj } try foo(0) 

No content

Let's speak about Tests 

XCTest brings no support. 

No content

! CatchingFire github.com/mrackwitz/CatchingFire 

enum BombError: ErrorType { case WrongWire case TimeElapsed } let ! = BombError.TimeElapsed let " = 11 let # = 12 func $(time: Int) throws { if time >= # { throw ! } } class ExampleTests : XCTestCase { func testDoNotDisarm() { AssertNoThrow(try $(")) AssertThrows(!, try $(#)) } } 

Swift's Builtin Error Throwing VS. Result type 

Integration with Standard Libraries 1 : 0 NSErrorPointer is vanished from the stdlib. 

Async 1 : 1 The try-catch model actively breaks the current control flow. But Result values can be passed around arbitrarily. 

Protocol-oriented Programming 2 : 2 A non-throwing method can fulfill a throwing protocol requirement. A Result type can be generically parameterized with a stub type NoError. 

Code Smells 

do { let object = try NSJSONSerialization.JSONObjectWithData(data, options: []) } catch { // should never happen } 

Better use try! let object : AnyObject = try! NSJSONSerialization.JSONObjectWithData(data!, options: []) 

But: try! is as bad as force unwrapping optionals 

Takeaways · Avoid try!, but prefer it instead of empty catch blocks. · Catch Foundation errors by pattern matches with NSCocoaError constructors · File a Radar if the error is not exposed / there is no obvious adequate 

Give it a try 

for question in questions { question.ask()! } 

Thanks for your attention! @mrackwitz [email protected]