この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
おばんです、昼飯に秋葉原をふらふらしていたら、たまたまラブライブの聖地の一つである竹むらさんを初めて見つけた田中です。甘いものは素直に好きなので今度甘味を食べに行ってみようと思います。
今日はかねてより参加したいと思っていた Swift実践入門読書勉強会 に参加させていただいたのでそのレポートをまとめます。今日のテーマはSwiftのエラー処理について。
Swift実践入門読書勉強会 #7 の概要
Swift実践入門の読書会を7回開催する予定で、これが最終回です。 想定している参加者は、Swiftの基本を最低限理解されていて、実務上、もっとSwiftyなコードを書きたい!と熱望されている方を対象としています。 ですので、Swift実践入門の前半にかかれている基本事項はこの勉強会では触れません。 今回は第13章 エラー処理からすすめていきます。
時間は80分程度、発表者を中心として本の解説をしていきますが、随時、質問や補足なども歓迎します。双方向な勉強会でみんなで学んでいきましょう！ 時間の制限があるので、本編から派生した面白い話は、FacebookグループやTwitterのハッシュタグ#read_swiftで展開されていければいいなあと考えています。
Connpass より引用
内容
Optional型を用いたエラー処理
Optional
そういえば、失敗可能イニシャライザーって、使った時に『失敗するかも知れない感じがコードに窺えない』のが気になることが時々あるのを、思い出して、再び気になってみた。 #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 型のお話。 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
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スタートブック読書勉強会とのことなので、ぜひご興味ある方はそちらもぜひご参加を！
6
