【ソフトウェア設計】例外処理を考える
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？ 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
例外だけに頼らない Kotlin のエラーハンドリング - Qiita
はじめに Java ではある処理がエラーになる可能性がある場合、チェック例外を使って呼び出し側にエラーハンドリングをさせることを強制できます。 一方、Kotlin にはチェック例外の仕組みがないため、チェック例外によるエラーハンドリングを強制できません。 そのためチェック例外を使った Java のコードを Kotlin に移植すると、エラーハンドリングがコンパイラ任せではなくコーディングルールによる対処になってしまいます。 実際に例外を使用した Kotlin のコードレビューをしたことがありましたが、コードレビューの負荷が増したと実感しました。 例えば次のような特定の入力に応じて例外を発生させる関数があるとして、その関数の呼び出しで適切に try-catch しているかはレビューやテストでしか確認できません。 class ParseException(message: String?) :
「例外を投げない」という選択肢をとる言語 - Qiita
新しめの言語では例外を投げることを推奨しない言語が出てきているように思えるが、そうした言語が例外をどう考え、例外の代わりにどのようなアプローチを奨励しているかを調べてみた。 本稿での「例外」とは、Javaのthrow構文のようにスコープを脱出してcatchされるまでエスカレートされる「投げる例外」のことを指し、エラーを表現したオブジェクト(エラーオブジェクト)については「例外オブジェクト」と呼び区別するものとする。(この2つを同一に扱うと、例外を使わないということは、エラーオブジェクトは使わないの？という話になるため) Go言語 - 例外はコードを複雑にする Go言語では、通常、エラーは戻り値として扱われる。(本当の本当に例外的なエラーのためにpanic, recoverがあるが、ほとんど使われることがないように見受けられる。) 例外がないGoでは、どう呼び出し元にエラーを伝えているかとい
エラーメッセージの読み方と対処, 検索や質問の原則 - Qiita
プログラミングをしている限り, エラーメッセージに遭遇するのは避けられないことだ. そこで, あなたは周りのできる人に「エラーが出ました」と言って "答え" を聞こうとするだろう. でも, もし聞ける人が誰もいなかったら? もし, 周りの誰にもわからないようなエラーにぶつかってしまったら? あなたが一人前のプログラマになるためには, 自分でエラーメッセージを読んで, 解決できるようにならなければならない. どういうエラーメッセージが出たときは何が原因で, どのように対処すれば解決するのか. その知識・経験の積み重ねこそがあなたを一人前のプログラマにするのだ. これは安直に "答え" だけを追い求めていてはいつまで経っても身に付かない. エラーメッセージの大原則 まず最初に頭に入れておくべきなのは, エラーメッセージは意味不明な暗号ではない ということだ. その実, エラーメッセージはかなり
Swiftのエラーハンドリングはなぜ最先端なのか - Qiita
Swiftのエラーハンドリングは他のメジャーなプログラミング言語のどれとも異なる新しい仕様を持っています。特に、検査例外を持っているのですが、これはJavaで採用された以降はほとんどの言語で採用されていないため、現代では否定されている過去の間違いだったと広く認識されていると思います。そのため、Swiftユーザーで無い人は、検査例外という言葉をみた瞬間に興味を失ってしまうため、その詳細がなかなか世の中に伝わっていないと感じています。一方、私はこんなSwiftのエラーハンドリングをとても気に入っていて、様々な言語の進化の歴史を踏まえた産まれた最も優れた最先端の仕様だと思っています。この記事ではその考えを説明します。 Javaのエラーハンドリング Javaは検査例外を持っています。これにより、あるメソッドがエラーを送出するかどうかを関数のシグネチャとして静的に表明できます。 // 検査例外の例
明日から使える実践エラーハンドリング
class: center, middle # 明日から使える<br/><strong>実践</strong><br/>エラーハンドリング Scala関西Summit 2018 11/10 --- class: left, middle ## 自己紹介 * 中村 学(Nakamura Manabu) * [@gakuzzzz](https://twitter.com/gakuzzzz) * Tech to Value 代表取締役 * Opt Technologies 技術顧問 <img src="../images/opt_logo_1.jpg" alt="Opt Technologies" width="450" style="margin-left: 0px" /> * F-CODE CTO <img src="../images/f-code_logo.png" alt="f-cod
Error Or Exception | そのエラーは例外ですか
Error Or Exception | そのエラーは例外ですか 1. そのエラーは例外ですか？ @nrslib nrs 2. 例外 3. 上手く使えてますか 4. エラーと例外 5. どう使い分けますか 6. 種類 7. 種類 回復可能 回復不可能 8. 種類 何かを変更すれば 回復可能 何かを変更しても 回復不可能 9. 種類 何かを変更すれば 回復可能 何かを変更しても 回復不可能 エラー 10. 種類 何かを変更すれば 回復可能 何かを変更しても 回復不可能 エラー 例外 11. 例えばユーザ一覧取得処理 12. 例えばユーザ一覧取得処理 ※システム的にグループ ID のバリデーション済で グループにユーザは必ず存在するものとします 13. 例えばユーザ一覧取得処理 14. グループにユーザが 見つかりません。 例えばユーザ一覧取得処理 15. グループにユーザが 見つかりません。
あなたのエラーコードは何ですか？
システムにおいて必ずといっていいほど存在するエラーコード。 このエラーコードってプロジェクトによってさまざまな形式だったりします。 そんなエラーコードとそのハンドリングで比較的上手くいっているパターンについてご紹介します。 具体的には列挙体を使ったエラーハンドリングです。 エラーコードの型は何ですか？ ソフトウェアやハードウェア、およそコンピュータに関わっていれば必ずといっていいほど目にするエラーコード。 皆さんが作っているシステム、日々携わっているシステム、それらのエラーコードってどのようなものでしょうか。 より具体的に言えばどんな型のエラーコードを取り扱っていますか？ 例えば数字です。 80011 こんなエラーコードがあるでしょう。 例えば文字列です。 'E1000' こういったエラーコードもあるでしょう。 色々なエラーコードが存在する世の中で今挙げたエラーコードを取り扱っている方もい
Failure is your Domain
By Ben Johnson, June 04, 2018 — 14 min read · pdf Go’s paradox is that error handling is core to the language yet the language doesn’t prescribe how to handle errors. Community efforts have been made to improve and standardize error handling but many miss the centrality of errors within our application’s domain. That is, your errors are as important as your Customer and Order types. An error also
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Error Patterns