なぜエラーを収集するのか バグ探し バグを見つけて潰していくため ユーザからのバグ報告の補助 ユーザに報告の負担をかけないため エラーを取得する 取得タイミング window.onerror Promise のエラー フレームワーク毎の特定のタイミング window.onerror window.onerror にメソッドを登録しておくことでエラー発生時にそのメソッドが呼ばれる。try-catch でハンドリングしていないエラーが流れてくる。
これは Swift Tweets の発表をまとめたものです(次回開催はこちら)。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました!Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし
PHP は各種プログラム言語の中でも比較的高級な (表現力が豊かで最適な記述を選ぶのに知識を必要とする) 例外モデルを持っていると言えます。そんな PHP の例外の各区分とその使い分けを整理し、PHP の例外モデルの設計意図を考察したいと思います。 PHP例外の分類 PHP の例外は Java とは異なり、(Error を合わせると) 合計 4 つの区分に分類されます。Java には 2 区分しかありません。(PHP では Java の Error に相当するものは発生しません。PHP の Error は Java では RuntimeException の一種に分類されています) PHP Java
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
GoConでは毎回エラー処理について面白い知見が得られる.Go Conference 2014 autumn においては(実際のトークではないが)居酒屋にて@JxckさんがRob Pike氏から以下のようなテクニックを紹介してもらっていた. Errors are values - The Go Blog Golang Error Handling lesson by Rob Pike これはWrite(やRead)のエラー処理が複数続く場合にerrWriter を定義して複数のエラー処理を一箇所にまとめてコードをすっきりとさせるテクニックであった. そして今回の Go Conference 2016 spring のkeynoteにおいてもDave Cheney氏から(僕にとっては)新たなエラー処理テクニックが紹介された. Gocon Spring 2016 実際に使ってみて/コードを読ん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く