明日から使える実践エラーハンドリング
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
あなたのエラーコードは何ですか？
システムにおいて必ずといっていいほど存在するエラーコード。 このエラーコードってプロジェクトによってさまざまな形式だったりします。 そんなエラーコードとそのハンドリングで比較的上手くいっているパターンについてご紹介します。 具体的には列挙体を使ったエラーハンドリングです。 エラーコードの型は何ですか？ ソフトウェアやハードウェア、およそコンピュータに関わっていれば必ずといっていいほど目にするエラーコード。 皆さんが作っているシステム、日々携わっているシステム、それらのエラーコードってどのようなものでしょうか。 より具体的に言えばどんな型のエラーコードを取り扱っていますか？ 例えば数字です。 80011 こんなエラーコードがあるでしょう。 例えば文字列です。 'E1000' こういったエラーコードもあるでしょう。 色々なエラーコードが存在する世の中で今挙げたエラーコードを取り扱っている方もい
複雑さに潜り込む - 大規模PHPアプリケーションにおける例外・モニタリング・ロギング - すずけんメモ
みなさん、PHP書いてますか？ここ2ヶ月くらいPHPも書いていたのでその話を書きます。 この記事はVOYAGE GROUP techlog / Advent Calendar 2016の記事です。 例えば以下のような話に身に覚えはありませんでしょうか。 例外がどこかで握りつぶされており、例外的状況なのにエラー表示がまちまち。レスポンスステータスも一貫性がない。エラーログが適切に出ていない。 エラーログ出力用コードがいろんなところで散乱している。エラー文字列整形のための適当なヘルパメソッドがクラスごとに実装されている。 エラーごとにエラー表示のためのメッセージを設定するのが面倒になり、「システムエラーが起きました」とだけ表示されるようになってしまった。 例外ハンドリング周りのコードは考えるのが面倒なのでコピペだらけになっている。 オブジェクトの依存関係がクラスのプロパティに大量に埋め込まれて
例外、エラー、異常、そして - 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割以下なら例外処理が勝った）けど、エラー処理っていうのは通常の処理よりも実行される回数は少ないのが普通なわけで、例外処理大好きっ子としては「例
Node.js における Promise を使った例外処理 - from scratch
さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基本的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(
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ページを開く
