明日から使える実践エラーハンドリング
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
例外、エラー、異常、そして - Qiita
「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 本来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected
例外処理は処理コストが掛かるらしいことを確かめようとしたら、意外とそうでもなかった話 - @katzchang.contexts
例外処理はパフォーマンスが低下するという話がよくあるので、確かめてみた。メソッド処理でエラーが起こった場合、返却値としてステータスコードを返すパターンと、例外を投げるパターンで処理時間を計測した。 で、下で示したコードで検証したところ、エラー発生時の処理コストはステータスコードを返すパターンの方が処理時間は少なかったけど、エラーが発生しない場合は例外処理を使うパターンの方が処理時間は少なかったという結果となった。 この検証では、パフォーマンス上の理由から例外処理機構を積極的に使うべきではないというのは根拠が薄いという結論です。厳密には期待されるエラー処理回数と正常処理回数の割合から採用を選ぶべきと言えるかもしれない（パラメータいじったら、エラー率が2割以下なら例外処理が勝った）けど、エラー処理っていうのは通常の処理よりも実行される回数は少ないのが普通なわけで、例外処理大好きっ子としては「例
Java/Androidにおける例外設計、あるいは「契約による設計」によるシンプルさの追求 - Qiita
なぜ今Javaの例外処理か Javaにおける「チェック例外」はSwift、Objective-C、Ruby、JavaScriptといったネイティブ・ウェブアプリ開発でよく用いられる他の言語には現れないものです。 SwiftにはOptionalやErrorTypeがありますが、Javaにおいてもnullやエラーのハンドリングの実装方法をうまくやる必要があります。 なぜ例外を握りつぶしたらいけないのか、なぜアサーションが望ましいのか、なぜチェック例外と非チェックを分けたのか、という点を考えてみたいと思います。 参考資料 例外設計における大罪 （契約プログラミングについて） Effective Java読書会9日目 - 例外 （Javaにおける例外の扱いについて） 契約による設計から見た例外 （この記事の方がより詳しいけど難しいイメージ） チェック例外と非チェック例外の違い チェック例外→「回復
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
