JavaScriptエンジニアなら知ってるよね？ エラー処理のいい書き方、悪い書き方
JavaScriptのエラー処理、ちゃんと書いていますか？ エラーを無視せず、どこに問題があるのか、きちんと確認できるコードの書き方をデモで紹介。 この記事はTim SeverienとMoritz Krögerが査読を担当しています。最良の記事を提供することができ、SitePointの査読担当者の皆さんに感謝します。 JavaScriptのエラー処理には危険が潜んでことを知っていますか？ もしマーフィーの法則を信頼しているとしたら、不具合が生じる可能性が本当に高いです！ この記事では、JavaScriptのエラー処理について考え、その落とし穴から便利な実践例までを説明します。さらに最後には、非同期コードとAjaxにも触れます。 JavaScriptはイベント駆動型プログラムで、プログラミングをより豊かなものにしてくれます。ブラウザーをイベント駆動型プログラムと考えると、発生するエラーは同一
Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
例外 - Qiita Advent Calendar 2014 - Qiita
例外やエラー、それにまつわる各種言語の取り組み等を共有しましょう。 11月末までに書き手が集まらなかった場合は主催者による独りAdvent Calendarと化します。 集まらなかったので残念ながら独りAdvent Calendarと化しました。 追記 独りAdvent Calendarですが、以下の理由で頓挫しました。6日目以降はお好きにご活用ください。 http://qiita.com/Kokudori/items/3a953c00012408f76ab9#%E4%BE%8B%E5%A4%96-advent-calendar-2014%E3%81%AE%E7%B6%99%E7%B6%9A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
例外入門以前 - Qiita
例外 Advent Calendar 2014の継続について 参加者が集まらなかったという経緯から独りAdvent Calendarとして始めた「例外 Advent Calendar 2014」ですが、諸事情により継続が困難となったため私Kokudoriの6日以降の投稿はありません。変に注目だけを集める形になってしまい申し訳ありません。 以下、諸事情というか、言い訳。 『契約による設計から見た例外』という記事にて述べた「契約」に対する私の理解が根本的に間違っていました。 そこから芋づる式に例外に関する私自身の考えが間違っていた、あるいは理解が浅かったことに気づきました。このような理解力では例外について私見を述べることさえ不可能となり、結果頓挫という形になりました。 考えうる限り最低で残念な結果になってしまいました。本当に申し訳ございませんでした。 初めに原則を考え出して、それから例外を見つ
Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱
二十五日半狂乱、6日目(の分...orz)の記事 Cのエラーハンドリングを毎回やるのは面倒だ！ 前回も言ったが、Cではエラーハンドリングに戻り値とerrnoを用いる． それはそうと例外設計において"無視"は大罪である． だから、関数を呼び出したら戻り値は漏らさずチェックすべきだ． ということで、例えば以下のように逐一戻り値をチェックする． if(send(sockfd, buf, len, 0) < 0){ ERROR("send"); exit(1); } あぁ、面倒だ． 一体コードのどの部分が正常系の処理なのか？ ほとんどエラーハンドリング*1で埋め尽くされるじゃないか． そもそもエラーハンドリング部分に書くのは毎回同じコードだし、コードの繰り返しは防ぎたい． エラー処理部分をラッピングして楽をする unpv12eの中でラッパーを被せることによってこの面倒を回避する方法を知った． in
java-ja の例外とロギング勉強会で発表してきました - 純粋関数空間
例外の勉強会をやるので、是非にというお話を頂いて、 LOG.debug(“nice catch!”) というイベントで発表させていただきました。 当日の資料はこちらでご覧になれます。 エラー処理の抽象化 昨年末頃に社内セミナーで発表した エラー処理を書いてはいけない をもうちょっと抽象的に、あるいは具体的な話を入れて焼き直したような内容です。 今回は java-ja さんの勉強会という事で、 なにやらモヒカンとかマサカリとかが飛んでくるらしい、 とんでもないところに来てしまったとビクビクしていましたが、 この難局も何とか乗り切りました。はい。 皆さんとても真面目にソフトウェアエンジニアリングについて議論していて、楽しかったです。 僕は普段Javaでコードは書かないのですが、 Javaだと普通こうする的なのが垣間見えて、 いろいろJavaのバッドノウハウ（あるいはグッドプラクティス）が学べま
エラー処理を書いてはいけない - Preferred Networks Research & Development
昨日セミナーとして USTREAM させていただいた資料を公開いたします。 エラー処理を書いてはいけない USTREAMのビデオ タイトルは釣り気味ですが、内容はいたって真面目なのでご安心ください。 概要 やってはいけないシリーズ、の第三弾としての試みです。 リソース管理をしてはいけない ロック処理を書いてはいけない エラー処理を書いてはいけない ← New！ タイトルに反して（あるいはタイトル通りに）、正しく長時間動作するプログラムを書くには きちんとエラー処理を行う必要がありますが、 それを何とか抽象化しようという（Haskell界隈での）試みについてのご紹介でございます。 あまり他の人がこういうことを言っているのを聞いたことが無いので、 自分の日々考えていることを世に問うた形になっております。 実際のところ、社内ではC++がメインに使われておりますので、 こういう手法が用いられている
エラーハンドリング勉強会で発表してきました - Yet Another Ranha
発表資料はココで : http://ranha.kerox.info/start_exception.pdf 全体構成は3部です。 しかし、そのうち1つは、Exceptional C++とか(何か聞く所に依るともっと適切な本があるらしいですが)読むと例外安全とか例外中立を一々気にする姿勢について分かるし良いのではないでしょうか、ということの紹介みたいなものなので、実質2つです。 Haskellのパートは,StackのPushを何も気にせず代数的データ構造で表現すると data Stack a = Empty | Push a (Stack a) となって、このPushの型が -- Push :: a -> Stack a -> Stack a Stack aというEmptyであるかもしれない型を返すのが良くない。 更に、PopってPushの逆操作だからーということで pop :: Stac
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外設計の話