狠狠撸

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

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

Error Handling ってなに？

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

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

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

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

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

これからの NSError
Swift 2.0

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

func removeItemAtPath(
path:String) throws -> Void
? 目的を遂行する
? エラーが発生するかもネ！
Swift 2.0

func contentsOfDirectoryAtPath(
path:String) throws -> [String]
? コンテンツが無ければ空の配列を返す
? エラーが発生するかもネ！
Swift 2.0

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

ところで
これまでの NSError は

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

それって安全じゃない

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

Swift は「安全」がお好き

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

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

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

Error Handling
Swift 2.0
正常系はこれ以降のスコープ全体

Error Handling
Swift 2.0
do {
}
正常系のスコープを明記！

Error Handling
Swift 2.0
do {
}
正常時の処理をこの中で決着する

Error Handling
Swift 2.0
do {
}
}
エラーが発生したらキャッチ！

Error Handling
Swift 2.0
do {
}
}
エラー時の処理をこの中で決着する

Error Handling
Swift 2.0
do {
}
}
エラー時はここは処理されない

Error Handling
Swift 2.0
do {
}
}
エラー時はここは処理されない
正常時の処理をこの中で決着する

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

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

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

Swift 1.2

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

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

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

エラーのときの后始末

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

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

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

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

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

こうなる
do {
defer {
handle.close()
}
}
catch {
}
? 事前準備が不要
? 流れが主役?
原則成功、ときどき失敗
? コードからエラーが?
発生する箇所がわかる

Error Handling は?
美しいってコト！

Swift でエラーを扱う方法

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

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

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

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

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

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

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

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

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

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

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

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

関数やメソッドで使う

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

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

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

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

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

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

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

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

Error Handling のイメージ

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

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

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

Swift は
すごいってコト！

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

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

Objective-C からの自動変換

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

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

Objective-C への自動変換

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

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

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

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

狠狠撸

Swift 2.0 の Error Handling #yhios

Recommended

More Related Content

What's hot (20)

Similar to Swift 2.0 の Error Handling #yhios (20)

More from Tomohiro Kumagai (20)

Swift 2.0 の Error Handling #yhios