---
title: Swift 2.0 の Error Handling #yhios
tags:  #swift #横浜へなちょこ勉強会 #error handling  
author: [熊谷友宏](https://convert.docswell.com/user/es_kumagai)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/KE49X5W5J1.jpg?width=480
description: Swift 2.0 で新登場した Error Handling についての特徴や使い方などを、これまでの Swift 1.x にもあったその他のエラー処理の方法と合わせて紹介してみました。  ※ Docswell での公開に移行する直前の Slideshare での閲覧数は 6,804 でした。
published: June 21, 15
canonical: https://convert.docswell.com/s/es_kumagai/59VW69-yhiosswifterrorhandling-150620215448-lva1-app6891
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/KE49X5W5J1.jpg)

Swift 2.0  の
ERROR HANDLING
2015.06.20  
@  横浜へなちょこ  iOS  勉強会  #35
EZ-‐‑‒NET  熊⾕谷友宏  
http://ez-‐‑‒net.jp/


# Page. 2

![Page Image](https://bcdn.docswell.com/page/L71KNWY2EG.jpg)

熊谷友宏
http://ez-net.jp/
@es̲kumagai
Xcode 5 徹底解説
MOSA
IP Phone
音でダイヤル
いつもの電卓
with 割勘ウォッチ
音で再配達ゴッド


# Page. 3

![Page Image](https://bcdn.docswell.com/page/G7WD46G2E2.jpg)

Error Handling ってなに？


# Page. 4

![Page Image](https://bcdn.docswell.com/page/4JZG2YL473.jpg)

NSError を
使いやすくするってコト！


# Page. 5

![Page Image](https://bcdn.docswell.com/page/YE6YVDWGJV.jpg)

エラーの話


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GE5GD3MXE4.jpg)

これまでの NSError
Swift 1.2
たとえば NSFileManager


# Page. 7

![Page Image](https://bcdn.docswell.com/page/972Y8Z9Q7R.jpg)

これまでの NSError
Swift 1.2
// オプショナルな NSError を状態として用意
var error:NSError? = nil
// 用意した NSError を inout で渡す
let succeeded =
fm.removeItemAtPath(path, error: &amp;error)
// エラーを検査する
if !succeeded, let error = error {
}


# Page. 8

![Page Image](https://bcdn.docswell.com/page/DJYG6R4YJM.jpg)

これまでの NSError
Swift 1.2
func removeItemAtPath(
path:String, error: NSErrorPointer)
-&gt; BOOL
▶ 戻り値で目的の結果を返す
▶ エラーのときは
NSErrorPointer で詳細を返す
▶ つまりエラーの詳細を知りたければ
NSError? を事前に別途用意する


# Page. 9

![Page Image](https://bcdn.docswell.com/page/V7NGZDYRE8.jpg)

これまでの NSError
Swift 1.2
func contentsOfDirectoryAtPath(
path:String, error: NSErrorPointer)
-&gt; [AnyObject]?
▶ 戻り値で目的の結果を返す
▶ コンテンツが無ければ空の配列を返す
▶ エラーがあったときは
▶ 戻り値で nil を返す
▶ NSErrorPointer で詳細情報を返す


# Page. 10

![Page Image](https://bcdn.docswell.com/page/YJ9WZGPZJ3.jpg)

これからの NSError
Swift 2.0


# Page. 11

![Page Image](https://bcdn.docswell.com/page/GJ8N1VXYED.jpg)

これからの NSError
Swift 2.0
// 正常処理のスコープを決める
do {
// 目的をまっすぐ達成する
try fm.removeItemAtPath(path)
}
catch let error as NSError {
// エラーならここで処理する
}


# Page. 12

![Page Image](https://bcdn.docswell.com/page/LJLPQ589ER.jpg)

これからの NSError
Swift 2.0
func removeItemAtPath(
path:String) throws -&gt; Void
▶ 目的を遂行する
▶ エラーが発生するかもネ！


# Page. 13

![Page Image](https://bcdn.docswell.com/page/47M4136VEW.jpg)

これからの NSError
Swift 2.0
func contentsOfDirectoryAtPath(
path:String) throws -&gt; [String]
▶ 戻り値で目的の結果を返す
▶ コンテンツが無ければ空の配列を返す
▶ エラーが発生するかもネ！


# Page. 14

![Page Image](https://bcdn.docswell.com/page/P7RWLQPWE9.jpg)

Error Handling で
正常系とエラー系とを分離


# Page. 15

![Page Image](https://bcdn.docswell.com/page/PJXPW53VEX.jpg)

ところで
これまでの NSError は


# Page. 16

![Page Image](https://bcdn.docswell.com/page/3JKDV6Y57D.jpg)

これまでの NSError
Swift 1.2
// NSError を用意しなくても実行可能
fm.removeItemAtPath(path, error: nil)
▶ 成否を戻り値だけで判定する
▶ 成功したものとして突き進むも可能


# Page. 17

![Page Image](https://bcdn.docswell.com/page/LE3RM69175.jpg)

それって安全じゃない


# Page. 18

![Page Image](https://bcdn.docswell.com/page/8EDY6VGKEG.jpg)

Swift は
そんなことはさせません


# Page. 19

![Page Image](https://bcdn.docswell.com/page/V7P6YV33J8.jpg)

Swift は「安全」がお好き


# Page. 20

![Page Image](https://bcdn.docswell.com/page/2JV3GZ4NEQ.jpg)

たとえば
func setAttributes(attributes,
ofItemAtPath:path) throws


# Page. 21

![Page Image](https://bcdn.docswell.com/page/5EG384157L.jpg)

Error Handling
Swift 2.0
エラーを未想定ならエラー
fm.setAttributes(attr, ofItemAtPath:path)


# Page. 22

![Page Image](https://bcdn.docswell.com/page/4JQ59GDL7P.jpg)

Error Handling
Swift 2.0
エラーを想定！
try fm.setAttributes(attr, ofItemAtPath:path)


# Page. 23

![Page Image](https://bcdn.docswell.com/page/K749X5Z5E1.jpg)

Error Handling
Swift 2.0
エラーを想定！
try fm.setAttributes(attr, ofItemAtPath:path)
正常系はこれ以降のスコープ全体


# Page. 24

![Page Image](https://bcdn.docswell.com/page/LJ1KNWR27G.jpg)

Error Handling
Swift 2.0
正常系のスコープを明記！
do {
try fm.setAttributes(attr, ofItemAtPath:path)
}


# Page. 25

![Page Image](https://bcdn.docswell.com/page/GJWD461272.jpg)

Error Handling
Swift 2.0
正常系のスコープを明記！
do {
try fm.setAttributes(attr, ofItemAtPath:path)
正常時の処理をこの中で決着する
}


# Page. 26

![Page Image](https://bcdn.docswell.com/page/4EZG2YP4J3.jpg)

Error Handling
Swift 2.0
do {
try fm.setAttributes(attr, ofItemAtPath:path)
}
catch let error as NSError {
エラーが発生したらキャッチ！
}


# Page. 27

![Page Image](https://bcdn.docswell.com/page/Y76YVDMGEV.jpg)

Error Handling
Swift 2.0
do {
try fm.setAttributes(attr, ofItemAtPath:path)
}
catch let error as NSError {
エラーが発生したらキャッチ！
エラー時の処理をこの中で決着する
}


# Page. 28

![Page Image](https://bcdn.docswell.com/page/G75GD3ZX74.jpg)

Error Handling
Swift 2.0
do {
try fm.setAttributes(attr, ofItemAtPath:path)
エラー時はここは処理されない
}
catch let error as NSError {
エラーが発生したらキャッチ！
エラー時の処理をこの中で決着する
}


# Page. 29

![Page Image](https://bcdn.docswell.com/page/9J2Y8ZRQJR.jpg)

まとめると


# Page. 30

![Page Image](https://bcdn.docswell.com/page/DEYG6RDYEM.jpg)

Error Handling
Swift 2.0
正常系のスコープを明記！
do {
エラーを想定！
try fm.setAttributes(attr, ofItemAtPath:path)
正常時の処理をこの中で決着する
エラー時はここは処理されない
}
catch let error as NSError {
エラーが発生したらキャッチ！
エラー時の処理をこの中で決着する
}


# Page. 31

![Page Image](https://bcdn.docswell.com/page/VJNGZD6R78.jpg)

つまり


# Page. 32

![Page Image](https://bcdn.docswell.com/page/YE9WZGLZE3.jpg)

エラーを確実に扱えるってコト！


# Page. 33

![Page Image](https://bcdn.docswell.com/page/GE8N1VWY7D.jpg)

next


# Page. 34

![Page Image](https://bcdn.docswell.com/page/LELPQ5N97R.jpg)

絶対エラーにならなくない？


# Page. 35

![Page Image](https://bcdn.docswell.com/page/4JM413XV7W.jpg)

絶対にエラーにならない
場合だってあるかもしれない


# Page. 36

![Page Image](https://bcdn.docswell.com/page/PJRWLQNW79.jpg)

これまでの NSError
Swift 1.2


# Page. 37

![Page Image](https://bcdn.docswell.com/page/PEXPW5NV7X.jpg)

これまでの NSError
Swift 1.2
// エラーチェックを記載しない
fm.setAttributes(attr,
ofItemAtPath:path, error:nil)
成否に関わらず以下が実行される


# Page. 38

![Page Image](https://bcdn.docswell.com/page/3EKDV6N5JD.jpg)

Error Handing
Swift 2.0


# Page. 39

![Page Image](https://bcdn.docswell.com/page/L73RM6V1J5.jpg)

Error Handling
Swift 2.0
// エラーはない ! と明記する
try! fm.setAttributes(attr,
ofItemAtPath:path)
エラーのときは以下に進まず 強制終了


# Page. 40

![Page Image](https://bcdn.docswell.com/page/87DY6V8K7G.jpg)

つまり


# Page. 41

![Page Image](https://bcdn.docswell.com/page/VJP6YV83E8.jpg)

無視するにも
覚悟が要るってコト！


# Page. 42

![Page Image](https://bcdn.docswell.com/page/2EV3GZNN7Q.jpg)

next


# Page. 43

![Page Image](https://bcdn.docswell.com/page/57G384K5JL.jpg)

エラーのときの後始末


# Page. 44

![Page Image](https://bcdn.docswell.com/page/4EQ59GNLJP.jpg)

Error Handling
do {
処理が終わったら閉じたい
let handle = try file.open()
try fm.setAttributes(attr, ofItemAtPath:path)
でもエラーが発生すると…
ここまでたどり着けない
handle.close()
}
catch {
}


# Page. 45

![Page Image](https://bcdn.docswell.com/page/KJ49X5G571.jpg)

Error Handling
do {
処理が終わったら閉じたい
let handle = try file.open()
最後に処理したいことを先に書く
defer {
handle.close()
}
try fm.setAttributes(attr, ofItemAtPath:path)
ここでエラーが発生しても…
ブロックを抜ける直前に処理される
}
catch {
}


# Page. 46

![Page Image](https://bcdn.docswell.com/page/LE1KNWD2JG.jpg)

余談


# Page. 47

![Page Image](https://bcdn.docswell.com/page/GEWD46Y2J2.jpg)

もしも Swift の Error Handling が
@try-catch-ﬁnally だったとしたら


# Page. 48

![Page Image](https://bcdn.docswell.com/page/47ZG2YX4E3.jpg)

もし try-ﬁnally だったとしたら…
var stream:Stream? = nil
@try {
初期化と後始末のスコープ分断を考慮して外側に定義
stream = Stream.open(path)
fm.setAttributes(attr, ofItemAtPath:path)
そもそも、どこでエラーが起こるの…？
}
@catch let error {
}
@finally {
未初期化を考慮してオプショナルチェイニング
stream?.close()
}


# Page. 49

![Page Image](https://bcdn.docswell.com/page/YJ6YVD4G7V.jpg)

つまり


# Page. 50

![Page Image](https://bcdn.docswell.com/page/GJ5GD3QXJ4.jpg)

こうではなく
var stream:Stream? = nil
@try {
stream = Stream.open(path)
fm.setAttributes(attr, ofItemAtPath:path)
}
@catch let error {
}
@finally {
stream?.close()
}
入れ物の事前準備が必要
▶ ３つのブロックに着目
▶ 流れよりも構文が主役
▶ どこでエラーになるかが
コードから読めない
▶


# Page. 51

![Page Image](https://bcdn.docswell.com/page/LE3RM6V475.jpg)

こうなる
do {
let handle = try file.open()
defer {
handle.close()
}
try fm.setAttributes(attr, ofItemAtPath:path)
}
catch {
}
事前準備が不要
▶ 流れが主役
原則成功、ときどき失敗
▶ コードからエラーが
発生する箇所がわかる
▶


# Page. 52

![Page Image](https://bcdn.docswell.com/page/8EDY6V85EG.jpg)

Error Handling は
美しいってコト！


# Page. 53

![Page Image](https://bcdn.docswell.com/page/V7P6YV8DJ8.jpg)

next


# Page. 54

![Page Image](https://bcdn.docswell.com/page/2JV3GZNGEQ.jpg)

Swift でエラーを扱う方法


# Page. 55

![Page Image](https://bcdn.docswell.com/page/5EG3845D7L.jpg)

Optional&lt;T&gt;


# Page. 56

![Page Image](https://bcdn.docswell.com/page/4JQ59GZX7P.jpg)

Optional&lt;T&gt;
値があるかないかを扱う型
▶ 値の有無による判断を強制
▶ 値がないときがエラーとは限らない
if let value = optional {
}
else {
// 値がなかったときにエラーとするかは状況次第
}


# Page. 57

![Page Image](https://bcdn.docswell.com/page/K749X532E1.jpg)

Optional のイメージ
？


# Page. 58

![Page Image](https://bcdn.docswell.com/page/LJ1KNW1K7G.jpg)

Optional&lt;T&gt;
使いどころ
▶ 単純に値の有無を提示する
▶ エラーかどうかを決め付けない
// 例えば、リストの中から値を検索する関数
func find(list, value) -&gt; Index? {
}


# Page. 59

![Page Image](https://bcdn.docswell.com/page/GJWD468P72.jpg)

いわゆる Either 型


# Page. 60

![Page Image](https://bcdn.docswell.com/page/4EZG2Y86J3.jpg)

いわゆる Either 型
どちらかの状況を表現する型
▶ 成功値か失敗値かを取る列挙型
▶ 成否というより状況の切り分けに着目
enum Result&lt;T&gt; {
case Success(T)
case Failure(Error)
}


# Page. 61

![Page Image](https://bcdn.docswell.com/page/Y76YVDPLEV.jpg)

いわゆる Either 型
どちらかの状況を表現する型
▶ 戻り値ひとつで状況の切り分けが可能
▶ 両者を同じ重みで扱う
switch getResult() {
case .Success(let value):
case .Failure(let error):
}


# Page. 62

![Page Image](https://bcdn.docswell.com/page/G75GD3KM74.jpg)

Either 型のイメージ


# Page. 63

![Page Image](https://bcdn.docswell.com/page/9J2Y8ZWRJR.jpg)

いわゆる Either 型
使いどころ
▶ 戻り値で二つの場面を提示する
▶ 背反する分岐点を表現する
// 成功したか失敗したかで進路を分岐する
enum Result&lt;T,U&gt; {
case Succeeded&lt;T&gt;
case Failed&lt;U&gt;
}
switch getResult() {
case .Success(let value):
case .Failure(let error):
}


# Page. 64

![Page Image](https://bcdn.docswell.com/page/DEYG6RL5EM.jpg)

Fatal Error


# Page. 65

![Page Image](https://bcdn.docswell.com/page/VJNGZD4478.jpg)

Fatal Error
致命的なエラー
▶ 処理が継続できない状況を表現
▶ 想定外を持ち越さない
fatalError(&quot;もうムリ…&quot;)
以降の処理は実行させない！


# Page. 66

![Page Image](https://bcdn.docswell.com/page/YE9WZGQ4E3.jpg)

Fatal Error のイメージ


# Page. 67

![Page Image](https://bcdn.docswell.com/page/GE8N1VGV7D.jpg)

Fatal Error
使いどころ
▶ Optional で絶対に値が入っているとき
▶ Optional で値が入っていないと困るとき
▶ try が絶対にエラーにならないとき
▶ 処理を継続できないと判断したとき
▶ 相手に責任を取らせたいとき
などなど
活用の場面は幅広い


# Page. 68

![Page Image](https://bcdn.docswell.com/page/LELPQ5GR7R.jpg)

実際


# Page. 69

![Page Image](https://bcdn.docswell.com/page/4JM413QP7W.jpg)

Fatal Error
Swift でも積極的に使われている
// 強制アンラップ
let value = optional!
値がなければ fatalError
// 暗黙アンラップなオプショナル
var value:String!
nil が入っているのに操作したら fatalError


# Page. 70

![Page Image](https://bcdn.docswell.com/page/PJRWLQ8Y79.jpg)

Fatal Error
Swift でも積極的に使われている
// 強制キャスト
let subObj = obj as! SubClass
キャストできなければ fatalError
// エラーを想定しない
try! execute()
エラーが起これば fatalError


# Page. 71

![Page Image](https://bcdn.docswell.com/page/PEXPW5847X.jpg)

Fatal Error で
想定外を想定内へ転換する


# Page. 72

![Page Image](https://bcdn.docswell.com/page/3EKDV6KPJD.jpg)

New!
Swift の Error Handling


# Page. 73

![Page Image](https://bcdn.docswell.com/page/L73RM6Z4J5.jpg)

エラー型の定義


# Page. 74

![Page Image](https://bcdn.docswell.com/page/87DY6VR57G.jpg)

Error Handling
ErrorType プロトコル
▶ エラー型を ErrorType で表現
▶ 実装を求められないプロトコル
▶ 列挙型と NSError が準拠できる
protocol ErrorType {
}


# Page. 75

![Page Image](https://bcdn.docswell.com/page/VJP6YVWDE8.jpg)

Error Handling
Error 型
▶ エラー型は 列挙型 で表現
▶ 列挙型を ErrorType に準拠させる
▶ 起こり得るエラーを列記
enum OpenError : ErrorType {
case NotFound
case Readonly
case Busy(reason:String)
}
値付き列挙子も使える


# Page. 76

![Page Image](https://bcdn.docswell.com/page/2EV3GZ8G7Q.jpg)

関数やメソッドで使う


# Page. 77

![Page Image](https://bcdn.docswell.com/page/57G384ZDJL.jpg)

Error Handling
エラーを示唆する
▶ エラーが有り得る機能に throws を付与
▶ エラーになるかもしれないことが
プログラマーとコンパイラの両者に伝わる
func open(file:FILE) throws -&gt; Stream {
:
:


# Page. 78

![Page Image](https://bcdn.docswell.com/page/4EQ59GLXJP.jpg)

Error Handling
エラーを通知する
▶ エラーは throw で通知する
▶ エラーは列挙子で指定する
▶ throws を指定した機能でだけ通知可能
func open(file:FILE) throws -&gt; Stream {
guard _exists(file) else {
throw OpenError.NotFound
}
:
:


# Page. 79

![Page Image](https://bcdn.docswell.com/page/KJ49X5D271.jpg)

使う側は
確実にエラーを想定


# Page. 80

![Page Image](https://bcdn.docswell.com/page/LE1KNWZKJG.jpg)

Error Handling
エラーを想定する
▶ 正常処理の範囲を do で表現
▶ エラーが発生し得る場所に try を明記
▶ エラーは catch で補足する
do {
let stream = try open(file)
}
catch {
}
エラーに挑む！


# Page. 81

![Page Image](https://bcdn.docswell.com/page/GEWD469PJ2.jpg)

Error Handling
全てのエラーに対処する
do {
let stream = try open(file)
}
catch OpenError.NotFound {
}
catch OpenError.ReadOnly {
}
catch OpenError.Busy(let reason) {
}


# Page. 82

![Page Image](https://bcdn.docswell.com/page/47ZG2Y96E3.jpg)

Error Handling
全てのエラーに対処する
do {
let stream = try open(file)
}
catch OpenError.Busy {
値付き列挙子の値を加味しないことも可能
}
catch is OpenError {
列挙子を加味せずに捕獲することも可能
}


# Page. 83

![Page Image](https://bcdn.docswell.com/page/YJ6YVDKL7V.jpg)

おさらい


# Page. 84

![Page Image](https://bcdn.docswell.com/page/GJ5GD3PMJ4.jpg)

Error Handling
おさらい
▶ エラーを列挙型で表現
起こり得るエラーが一目瞭然
▶ エラーの可能性を throws で示唆
プログラマーとコンパイラに意思が伝わる
▶ エラーが起こり得る箇所に try を明記
どこでエラーを想定しているかが明確
▶ エラーを想定したコードが必須
強制されると悩まずに済むので楽になる


# Page. 85

![Page Image](https://bcdn.docswell.com/page/9E2Y8Z6RER.jpg)

つまり


# Page. 86

![Page Image](https://bcdn.docswell.com/page/D7YG6R957M.jpg)

Error Handling で
とっても楽になるってコト！


# Page. 87

![Page Image](https://bcdn.docswell.com/page/VENGZDL4J8.jpg)

Error Handling のイメージ


# Page. 88

![Page Image](https://bcdn.docswell.com/page/Y79WZG4473.jpg)

Error Handling
使いどころ
▶ 達成すべき目的があり
それを達成できない可能性があるとき
▶ 原因が実行時エラーに限られるとき
▶ 原因がいくつか考えられるとき
▶ 原因を提示し、対応を求めたいとき
// 目的が明確で、エラーも有り得る複合的な機能
func open(file:FILE) throws -&gt; Stream


# Page. 89

![Page Image](https://bcdn.docswell.com/page/G78N1VQVJD.jpg)

まとめ


# Page. 90

![Page Image](https://bcdn.docswell.com/page/L7LPQ5XRJR.jpg)

エラーを扱う手段
？
Optional 型
▶ 単純に値の有無を提示
いわゆる Either 型
▶ 戻り値で分岐点を提示
Fatal Error
▶ 強制終了して根本的な改善を迫る
Error Handling
▶ 目的を遂行できない時に原因を提示


# Page. 91

![Page Image](https://bcdn.docswell.com/page/4EM413LPJW.jpg)

Swift はこれらの使用を強要する
強要されると
プログラミングが楽になる
？


# Page. 92

![Page Image](https://bcdn.docswell.com/page/PERWLQKYJ9.jpg)

つまり


# Page. 93

![Page Image](https://bcdn.docswell.com/page/P7XPW5L4JX.jpg)

Swift は
すごいってコト！


# Page. 94

![Page Image](https://bcdn.docswell.com/page/37KDV6LPED.jpg)

おしまい。
▶ Error Handling ってなに？
▶ NSError を使いやすくするってコト！
▶ エラーを確実に扱えるってコト！
▶ 無視するにも覚悟が要るってコト！
▶ Error Handling は美しいってコト！
▶ Error Handling でとっても楽になるってコト！
▶ Swift はすごいってコト！


# Page. 95

![Page Image](https://bcdn.docswell.com/page/LJ3RM634E5.jpg)

おまけ


# Page. 96

![Page Image](https://bcdn.docswell.com/page/8JDY6V45JG.jpg)

Objective-C のことも
Swift は見捨てない


# Page. 97

![Page Image](https://bcdn.docswell.com/page/VEP6YVMD78.jpg)

Objective-C からの自動変換


# Page. 98

![Page Image](https://bcdn.docswell.com/page/27V3GZ9GJQ.jpg)

Objective-C からの自動変換
末尾の NSError を throws に変換
▶ 戻り値がクラスの場合
▶ 最後の引数が NSError** の場合
// このような Objective-C コードが
- (NSString*)getNameFromPath:(NSString*)path
error:(NSError**)error;
// このような Swift コードになる
func getNameFromPath(path:String!)
throws -&gt; String


# Page. 99

![Page Image](https://bcdn.docswell.com/page/5JG3844DEL.jpg)

Objective-C からの自動変換
末尾の NSError を throws に変換
▶ 戻り値が BOOL の場合
▶ 最後の引数が NSError** の場合
// このような Objective-C コードが
- (BOOL)prepareWithOptions:(NSArray*)opts
error:(NSError**)error;
// このような Swift コードになる
func prepareWithOptions(opts:[AnyObject]!)
throws -&gt; Void


# Page. 100

![Page Image](https://bcdn.docswell.com/page/47Q59GGXEP.jpg)

Objective-C への自動変換


# Page. 101

![Page Image](https://bcdn.docswell.com/page/KE49X552J1.jpg)

Objective-C への自動変換
throws を NSError に変換
▶ 戻り値が @objc 互換オブジェクトの場合
▶ throws が指定されている場合
// このような Swift コードが
func getName(path:String) throws -&gt; String
// このような Objective-C コードになる
- (NSString*)getName:(NSString*)path
error:(NSError**)error;


# Page. 102

![Page Image](https://bcdn.docswell.com/page/L71KNWWKEG.jpg)

Objective-C への自動変換
throws を NSError に変換
▶ 戻り値が Void の場合
▶ throws が指定されている場合
// このような Swift コードが
func prepare(options:[String]?) throws
// このような Objective-C コードになる
- (BOOL)prepare:(NSArray**)options
error:(NSError**)error;


# Page. 103

![Page Image](https://bcdn.docswell.com/page/G7WD466PE2.jpg)

安心して
Error Handling を活用できる


# Page. 104

![Page Image](https://bcdn.docswell.com/page/4JZG2YY673.jpg)

つまり


# Page. 105

![Page Image](https://bcdn.docswell.com/page/YE6YVDDLJV.jpg)

Swift は
かっこいいってコト！


# Page. 106

![Page Image](https://bcdn.docswell.com/page/GE5GD33ME4.jpg)

おしまい。


