Swift 2 - Error Handling

An overview about Swift 2's new built-in error handling, an exploration how it works and how it can be tested, and a quick comparison with the approach of a Result type.

Transcript

1. Swi! 2 Error Handling
4. 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 } }
5. 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 }
6. 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.") }
7. Throwing, NonThrowing and ReThrowing
8. Take a Look into the Book
9. A throwing method can’t override a nonthrowing method, and a throwing method can’t satisfy a protocol requirement for a nonthrowing method. …
10. … That said, a nonthrowing method can override a throwing method, and a nonthrowing method can satisfy a protocol requirement for a throwing.
11. Non Throwing ⊂ Throwing
12. Model protocol ThrowingFunction { typealias ParameterType typealias ReturnType func call(parameter: ParameterType) throws -> ReturnType } protocol NonThrowingFunction : ThrowingFunction { func call(parameter: ParameterType) -> ReturnType }
13. How does rethrows fits in?
14. rethrows is the shapeshifter
15. 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)") }
16. as nonthrowing var x = 0 parse(str) { (char) in if char == "+" { x += 1 } }
17. Limits You can just try the closure. Trying something else is forbidden. !
18. ErrorType demystified
19. // from SwiftExP public enum Error : ErrorType { case UnexpectedEOS case IllegalNumberFormat(numberString: String) case IllegalEscapeSequence(escapeSequence: String) case NonTerminatedList case NonTerminatedQuotedString case IllegalHexCharacter(char: Character) }
20. protocol ErrorType { }
21. (lldb) type lookup ErrorType protocol ErrorType { var _domain: Swift.String { get } var _code: Swift.Int { get } }
22. Implements some Protocols by Default · Hashable · Equatable
23. 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 } }
24. Swift's Error Throwing under the hood
25. Swift's Error Throwing under the hood · Breaks the control flow · Syntax sugar around NSError pointers · Isn't as expensive as Objective-C exceptions
26. 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)
28. Let's speak about Tests
29. XCTest brings no support.
31. ! CatchingFire github.com/mrackwitz/CatchingFire
32. 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 $(#)) } }
33. Swift's Builtin Error Throwing VS. Result type
34. Integration with Standard Libraries 1 : 0 NSErrorPointer is vanished from the stdlib.
35. Async 1 : 1 The try-catch model actively breaks the current control flow. But Result values can be passed around arbitrarily.
36. 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.
37. Code Smells
38. do { let object = try NSJSONSerialization.JSONObjectWithData(data, options: []) } catch { // should never happen }
39. Better use try! let object : AnyObject = try! NSJSONSerialization.JSONObjectWithData(data!, options: [])
40. But: try! is as bad as force unwrapping optionals
41. 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
42. Give it a try
43. for question in questions { question.ask()! }
44. Thanks for your attention! @mrackwitz mr@realm.io