Upgrade to Pro — share decks privately, control downloads, hide ads and more …

エラーアーキテクチャ設計について考える/Thinking about error architecture design

きちえもん
September 20, 2020

エラーアーキテクチャ設計について考える/Thinking about error architecture design

きちえもん

September 20, 2020
Tweet

More Decks by きちえもん

Other Decks in Technology

Transcript

  1. — モチベーション — iOSアプリでエラーハンドリングを改善した話 — Androidアプリでエラーハンドリングを改善した話 — エラーアーキテクチャ設計について考える Agenda 今日話すこと

    #iOSDC Japan 2020 ※ 資料で登場するコードは、骨子以外を省いて簡素化したものです。 そのまま利用できるとは限りません。
  2. onErrorでエラー型を指定するためにラッパークラス を定義した UseCaseResult<T, E: UseCaseError> エラーケースは enum で表現し、コンパイルで漏れ を検知できるようにした UseCase毎にエラーケースを定義し、個別エラーを表

    現できるようにした 1. i. 2. 3. まとめ iOS アプリで したこと 2つの課題感 エラーケースを型で表現できない 考慮漏れをコンパイル時に検知できない 1. 2. 取り組んだこと
  3. Android アプリ で したこと FeatureSpecificというケースを追加 機能固有のエラーケースは別で定義して表現 共通変換処理に、個別変換を差し込めるようにする toUseCaseLayerReturns() -> Either<UseCaseLayerException,

    T> 基本的なエラーケースは共通で処理する方針は維持 1. a. 2. i. 3. まとめ 課題感 個別のエラーを個別処理できない 1. 取り組んだこと #Android アプリ
  4. ここまでの 点 # エラーについて える エラーケースを型で 表現できない Singleをラップした独自型を作成 エラー型を個別に指定できる形へ 1

    エラーケースの漏れが発生 する可能性 2 エラーケースは列挙型で表現する 3 機能固有のエラーケースを 個別に処理できない 共通変換処理をベースにしつつ、 個別変換を差し込めるようにする
  5. 型で制約をかける 列挙型を利用する 固有エラーは個別に処理する 1. 2. 3. 3つのポイント # エラーについて える

    どんなエラーが存在しているか 強調している ユースケースそれぞれの独立性を高めて、 その他の関心事から切り離している
  6. Single<T> から UseCaseResult<T, Error> への 更を り る # エラーについて

    える Single<T> UseCaseResult<T, AppUseCaseError> 晴れの日のシナリオは表現できているが、 雨の日のシナリオは実装依存になっている。 雨の日のシナリオを、AppUseCaseErrorで表現。 どんな雨の日を考慮すべきかが明確に定義されている。 onError: (error: Error) in onError: (error: AppUseCaseError) in
  7. Single<T> から UseCaseResult<T, Error> への 更を り る # エラーについて

    える Single<T> UseCaseResult<T, AppUseCaseError> 晴れの日のシナリオは表現できているが、 雨の日のシナリオは実装依存になっている。 雨の日のシナリオを、AppUseCaseErrorで表現。 どんな雨の日を考慮すべきかが明確に定義されている。 onError: (error: Error) in onError: (error: AppUseCaseError) in 雨の日のシナリオをどうやって表現するか、を考えていくことが、 エラーアーキテクチャを設計する、ということ
  8. エラーアーキテクチャは、 ⾬の⽇シナリオを主 する は仕 みで る ⾬の⽇のシナリオは問いで抽 それぞれのユースケースは に ユースケースは、アプリにとっての存在意義

    晴れの日、雨の日の両面で考えて考慮 列挙型は「どんな雨の日があるか」を主張するのに有用 I/Fでエラー型を明示することで、アピール 機能が増えるほど、ユースケースは増えていく それぞれの知識が混ざり合わないように注意したい あるユースケースの変更が、外に伝搬しないようにしたい ユースケース毎に雨の日を定義できる仕組みが望ましい より早い段階で実装に気付けるようにする コンパイルで気付けるのが望ましい 考慮もれに気付ける仕組み 方針があっても、それに沿えるかどうかは別問題 雨の日を表現するのに、必ずしも型で表現しなくても良い しかし、型で表現できた方が制約が強く表現力が高い 基本ケース以外に、他に何が起きるか?を問いかけ続ける エラーアーキテクチャ設計まとめ # エラーについて える