文字列を整数値にするような取るに足りない処理でいちいちエラーハンドリングを強制するのは過剰である、こういったことでエラーが投げられることは相対的にエラーの重みを軽くしてしまう、などの意見。してパースする関数はどうだろう。これについても一番下のシグネチャは明らかに適切でない。する真ん中のシグネチャがよいのではないか。するのか、どちらのインターフェースが好ましいのだろう。現実的にはコンテキストに依存することもあるだろうし、現在のところ一定した結論はない。関数であってもエラーを無視するのが容易になった。できるようになったこともまたこの議論に影響する。オブジェクトから何らかの型の値にマッピングするとき、本来存在するべきキーが存在しなかったり、予期しているものと違う型の値が入っている場合に、それをエラーとしてレポートしたい。定義するのが良いのだろうか。丁寧に作られるべきである。実装し、エラーを読みやすくする工夫もあると良いだろう。した際の可読性を改善できるできることは他にもある。エラーを投げる関数の側に、ドキュメンテーションコメントを利用してどのようなエラーが投げられ得るか記述しておくことができる。これはその関数の利用者にとって有益な情報になるはずだ。型にキャストすることができる。キャストができるのは不自然である。暗黙的な変換が内部で行われている。役割の広い型であった。デフォルトの実装が使われる。デフォルトの実装はユーザーインターフェイスとの連携にあまり適さず、これまでのようにエラーをユーザーインターフェイスに反映させるのが難しくなった。いうクラスメソッドを持つ。辞書に存在しない場合に利用される。ユーザーインターフェイス向けの情報が設定されていなくても、オンデマンドにそれらを設定できるのである。この状態から元のエラーの原因を識別し、意味のある情報を得るのは難しい場合も多い。して取り扱うのはあまり筋が良くない。持っていた情報や機能が失われてしまう。いった機能をつけるのが良いのではないか。オブジェクトを得られるのではないか。ソフトウェアを書こうとする私たちが直面する大きなテーマである。エラーハンドリングだけを取り上げたとしても、ここまでに述べたような多様な問題や選択肢が存在している(それに加えて非同期のエラーハンドリングというさらに大きな問題がある)。アプリ開発の定石を発見していきたい。発表し、議論した内容を簡単にまとめたものです。検索リンクはてなブログブログをはじめる(無料)お知らせ最新記事SwiftUIではSingletonの代わりにEnvironmentを使うことができる紛らわしい文字列をもっと紛らわしくするapple/swift-formatを試す息子にカメラを与えるCoreImage.CIFilterBuiltins月別アーカイブはてなブログをはじめよう!cockscombさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。