[イベントレポート] Swift実践入門読書勉強会 #7 に参加してきました #read_swift

はじめに

おばんです、昼飯に秋葉原をふらふらしていたら、たまたまラブライブの聖地の一つである竹むらさんを初めて見つけた田中です。甘いものは素直に好きなので今度甘味を食べに行ってみようと思います。

今日はかねてより参加したいと思っていた Swift実践入門読書勉強会 に参加させていただいたのでそのレポートをまとめます。今日のテーマはSwiftのエラー処理について。

Swift実践入門読書勉強会 #7 の概要

Swift実践入門の読書会を7回開催する予定で、これが最終回です。 想定している参加者は、Swiftの基本を最低限理解されていて、実務上、もっとSwiftyなコードを書きたい!と熱望されている方を対象としています。 ですので、Swift実践入門の前半にかかれている基本事項はこの勉強会では触れません。 今回は第13章 エラー処理からすすめていきます。

時間は80分程度、発表者を中心として本の解説をしていきますが、随時、質問や補足なども歓迎します。双方向な勉強会でみんなで学んでいきましょう！ 時間の制限があるので、本編から派生した面白い話は、FacebookグループやTwitterのハッシュタグ#read_swiftで展開されていければいいなあと考えています。

Connpass より引用

内容

Optional型を用いたエラー処理

Optional型を使うことで、nilを扱うことができるようになります。エラーの理由など、詳しい情報が必要ない場合は関数などの戻り値がnilであるかどうかということなどをエラー処理として簡易的に表すことができます。これは失敗可能イニシャライザなどでも扱われます。

そういえば、失敗可能イニシャライザーって、使った時に『失敗するかも知れない感じがコードに窺えない』のが気になることが時々あるのを、思い出して、再び気になってみた。 #read_swift

— 熊谷 友宏 (@es_kumagai) 2017年5月24日

失敗可能イニシャライザはエラー処理を簡潔に記述できる点がメリットとしてある。 #read_swift

— ダンボー田中@Push通知下手マン (@ktanaka117) 2017年5月24日

どんな時に使う？
->石川さん:enumを初期化したいとき、jsonからenumを初期化できない時。初期化できないのはjsonがマッチしてないということだけわかればいい

— SatoTakeshi (@hatakenokakashi) 2017年5月24日

Result型を利用したエラー処理

Optional型と比較して、Result型を用いるとエラーの詳細を連想値として渡すことができるので、より詳細にエラーの情報を得ることができます。また、Result型は必ず成功か失敗のどちらかの結果に当てはまるので、エラー時の想定し得なかった不正なパターンのリスクを考慮する必要がなくなる利点があったり、エラーの型を保持したまま呼び出し元に伝播することができるので、どんなエラーが返ってくるかというパターンが絞られるという点も大きなメリットとして挙げられます。

簡易的なResult型の実装の他に、より高機能なResult型の紹介もされました。

Result 型のお話。 https://t.co/ExvuNzhVuu #swift #read_swift pic.twitter.com/9i7gQ3vOSo

— 熊谷 友宏 (@es_kumagai) 2017年5月24日

Result型とSwitchでErrorを扱う網羅性はとても強力。その網羅性のみでなく、特定のError型に対してどういうErrorが発生しうるかというのが一目瞭然になるのがまた素晴らしい。 #read_swift

— ダンボー田中@Push通知下手マン (@ktanaka117) 2017年5月24日

do-catch文を利用したエラー処理

do-catch文もOptional型と比較して、より詳しいエラーの情報を取得することができます。do-catch文の長所としては、複数の型のエラー文を一律で扱うことができるということ。またその反面としてエラーのthrow時にはエラーの型情報がなくなってしまうため、どんなエラーが返却されるかという型の推論ができなくなってしまう短所も紹介されました。

catchには型情報がなくなっている。この例ではcatch SomeError.error1はcatchの後の型はError型の何かが来るとしか不明 https://t.co/YJYsCoVype #swift #read_swift pic.twitter.com/Lm1twj3Wq8

— SatoTakeshi (@hatakenokakashi) 2017年5月24日

よくわからないエラーはunknownと定義する#read_swift

— SatoTakeshi (@hatakenokakashi) 2017年5月24日

この時点で型情報がなくなっているって見方、なるほどなるほど #read_swift

— Yutaro (@yutailang0119) 2017年5月24日

do-catchによるエラー処理は、Result型によるエラー処理と比較した時に、複数のパターンのエラーに対処できるという利点がある #read_swift

— ダンボー田中@Push通知下手マン (@ktanaka117) 2017年5月24日

do-catch文とthrowsによるエラー処理にdefar文を活用する

throwsキーワードをつけた関数ではエラーがthrowされた時点でそれ以降の処理を中断してしまいますが、defar文を活用することで、エラーの有無に関わらず行いたい処理をそのスコープを抜ける直前に行うことができるとのことでした。

なるほど？deferってそう使うのか。全然使ったことなかった #read_swift

— ダンボー田中@Push通知下手マン (@ktanaka117) 2017年5月24日

deferはそのスコープの終了後に行われる処理なので、エラーで処理が止まった後にも実行したい処理、エラーの有無に関わらず行いたい処理があるばあいに使える #read_swift

— ダンボー田中@Push通知下手マン (@ktanaka117) 2017年5月24日

あー、なるほどエラー処理の時に使えば良いのか。納得した。 #read_swift

— ワニ@tmk (@alligator_tama) 2017年5月24日

rethrowsキーワードについて

throwsキーワードを利用するクロージャを引数に持った関数に対して使うrethrowsキーワード。引数として受け取ったクロージャによってthrowされるエラー以外を認めない性質の模様。

.@_ishkawa 「rethrowsを自分から出会いに行くことは、まず訪れない」 #read_swift

— Yutaro (@yutailang0119) 2017年5月24日

rethrowsは汎用的なものを書くときに登場したりする。map, filter, reduceなどには実装されていて、みんな知らないうちに恩恵に預かっていたりする #read_swift

— ダンボー田中@Push通知下手マン (@ktanaka117) 2017年5月24日

違った。これにおいて、throwingClosure()は引数からきているのだからおk。それ以外のところからのthrowはダメよってことね https://t.co/HeICjnCmpX #swift #read_swift pic.twitter.com/CrpirLg2I1

— ダンボー田中@Push通知下手マン (@ktanaka117) 2017年5月24日

flatMapでResult型を扱う場合と、定義の解説

Result型を扱っていると遭遇しがちなswitchでネストするResult型。とても読みにくくなっていきがちですが、flatMapを使うことでうまく回避できるという話。

著者である石川氏直接のライブホワイトボーディング。

以下のリンクのflatMapの実装がまさに該当する実装とのこと。

石川さんがホワイトボードに書かれたコード。https://t.co/Sje8VQs6bMではResult型にflatMap … https://t.co/jAOCBH3kIi #swift #read_swift pic.twitter.com/LeqMHaCqmn

— SatoTakeshi (@hatakenokakashi) 2017年5月24日

このとき、r1とr2のResult型のErrorは同じ型でなければいけないという制約があるとのこと #read_swift https://t.co/66apJ643X6

— ダンボー田中@Push通知下手マン (@ktanaka117) 2017年5月24日

さいごに

第13章のエラー処理について触れた今日の会で最終回を迎えたSwift実践入門読書勉強会さん。これまで「なんとなく」での理解でいたSwiftのより良い利用方法を多く知ることができたので大満足でした。また、今回は著者である石川氏が急遽参加することとなり、最終回にふさわしい、素晴らしい会だったなと感じました。

今度からはKotlinスタートブック読書勉強会とのことなので、ぜひご興味ある方はそちらもぜひご参加を！