Promise Error Handling
Promise Error Handling 約束されたエラー Promiseとエラーの基本 Promise内で起きた例外は自動でキャッチされる エラー処理は.catch(fn)で行う var promise = new Promise(function(){ throw new Error("例外"); }); promise.catch(function(error){ // 例外をキャッチできる }); よくある問題 .catch(fn) をしないとエラーログも出せない .catch(fn) をしわすれてエラーの握りつぶしが起きる = unhandled rejection (.catchをしてないpromise) 4.6. Promise.prototype.done とは何か? 現状のunhandled rejectionへの対応 unhandled rejectionが発生した
#error_handling_sushi でPromiseのエラーハンドリングについて発表した
#error_handling_sushi でJavaScriptのエラーハンドリングについて議論した。 自分はPromiseのエラーハンドリングの握りつぶしの問題を見つけやすくするイベントの実装について、Promise Error Handlingという話をした。 ログ: #error_handling_sushi - Togetterまとめ #error_handling_sushi 始まった #寿司とは pic.twitter.com/XZe21QTsDO — Takuto Wada (@t_wada) March 6, 2015 – 基調講演 - teppeis これが #error_handling_sushi pic.twitter.com/vSLDpthYi4 — azu (@azu_re) March 6, 2015 #error_handling_sushi 基調講演 一
非同期APIと例外処理（node.js の domain について）
node.js のような非同期APIを使ったプログラミングに拒絶反応を示すエンジニアが多い理由の一つが、非同期APIと例外処理の相性の悪さだ。 Javascript の場合、例外処理はこんな感じに記述する。 function f(i) { try { throw new Error('an error #'+ i); } catch(e) { console.log('Error caught:', e.message); } } ところが、これに非同期APIが絡むと、とたんに分かりにくくなる。例えば下の例。 function f(i) { try { setTimeout(function() { throw new Error('an error #'+ i); }, 1000); } catch(e) { console.log('Error caught:', e.message)
Java7 体当たり／try-with-resources Statement - 日々常々
JDK7 を使う準備が出来たので、体当たりします。 Java7 での個人的に嬉しいのが try-with-resources Statement です。AutoCloseable （を実装したクラス）の変数をこの構文で初期化すると、勝手に close してくれるってものです。 ではさらっと使ってみます。 public class TryWithResources { public static void main(String[] args) { try (AutoCloseable imp = new AutoCloseableImpl()) { // New! System.out.println("hoge"); } catch(Exception e) { System.out.println("catch:" + e); } finally { System.out.printl
The "catch" with try...catch - performance, web applications - Bocoup
I’ve recently been working on an update to JavaScript Debug, which has me doing a lot of cross-browser testing, and I noticed a few “interesting quirks” with try…catch in Internet Explorer 6-8 that I couldn’t find documented anywhere. The BackstorySince the primary goal of JavaScript Debug is to normalize the console cross-browser, I’ve been doing a lot of in-depth logging, passing large quantitie
NullPointerExceptionなどの標準例外を使っていないわけ - taediumの日記
Domaでは、Daoのメソッドに期待されない引数（nullとか）が渡された場合に例外をスローしますが、そのときの例外にNullPointerExceptionやIllegalArgumentExceptionを使っていません。代わりに、DomaNullPointerExceptionやDomaIllegalArgumentExceptionといったDoma独自の例外を投げます。 これはなぜかというと、Daoのメソッドに対する事前条件を満たしていないのか、それともDoma自身にバグあって例外がスローされてしまっているのをわかりやすくするためです。 つまり、DomaNullPointerExceptionやDomaIllegalArgumentExceptionがスローされるということは、「これはDomaが意図的にスローしています。なんらかの条件を満たしていません。」というメッセージです。そし
オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ
「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤解あり - じゅんいち☆かとうの技術日誌のあんまりな釣りタイトルにやれやれだぜ、と思いつつも非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESSでツッコミたかったことが突っ込まれてしまってるので、しょうがないのでオブジェクト指向と型システムの話でもしよう。 Javaの静的型システム ≠ オブジェクト指向 僕が10年ほど前、Javaを使い始めてからしばらくたってやっとオブジェクト指向プログラミングが掴めて楽しくなってきた頃合、これこそがオブジェクト指向なのだと誤解をしていたころ、オブジェクト指向は型がチェックできてなんぼだと思ってた。 javascriptのプロトタイプ型のオブジェクト指向に憤り、「あんなものはオブジェクト指向ではない」などと思うのがJavaプログラマ的中二病というやつだが
非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS
まず、以下に持論を展開するにあたって、自分の立ち位置を明確にしよう。自分は「Webアプリケーション開発者」としてではなく「JavaによるWebアプリではない（デスクトップアプリ,コマンドラインアプリ,ライブラリ）アプリの開発者」として語る。まぁ、自分に一番馴染みの深いプロダクトとしてJiemamyが挙げられるわけだが、こいつはWebアプリじゃない。Eclipse上で動くアプリケーションであり、そしてMaven2によって呼ばれるCLIアプリでもあり、また、クラスライブラリである。 この視点からJavaにおけるチェック例外と非チェック例外の話を再び。 Javaにおけるthrows句は、メソッドシグネチャの一部であり、インターフェイスにも現れる情報である。今まで「Javadocは仕様だ」と言い続けて来たが、正確にはインターフェイス（シグネチャ＋Javadoc）が仕様だ。*1 検査例外が使いにくい
Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS
1st Seasonはこちら。Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS 以前は、何かをスローする状況を3つに分けてそれに合った設計をした例外を投げましょう、という考え方を示しました。 callerのバグ: RTE calleeのバグ: Error どちらでもない: Exception (非RTE) まぁ詳しくはSeason1の方で。 Seasar2はRuntimeExceptionですね。2004年ぐらいからのフレームワークはRTEをスローしていると思いますよって、ひがさんから情報。 チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌 ただ、上記のような考え方もあるのも事実。実際.NETやRuby, Python, 新鋭のScala等もcatchを強制する例外というものが言語仕様的に存在しません*1。逆に、チェック例
チェック例外がJavaにあってC#にない理由 - かとじゅんの技術日誌
例外の再考 - じゅんいち☆かとうの技術日誌 に引き続き、チェック例外がJavaにあってC#*1になぜがないか考察してみようと思います。 また、いろいろググっているとよい記事がありました。 なぜ C# の言語仕様に検査例外がないのか？という記事。 "Why doesn't C# have exception specifications?" http://msdn.microsoft.com/en-us/vcsharp/aa336812.aspx 基本原文読んでくださいね。私の英語力は当てにならないのでw ここで言及しているのは以下の項目。順におっかけてみよう。 Versioning Productivity and code quality Impracticality of having class author differentiate between "checked" and
例外の再考 - かとじゅんの技術日誌
愛する部下の一人がよいエントリを書いてくれたので、私も重い腰をあげてみたw Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS 短時間で、ようまとめたなーw チェック例外は、Java以外の言語では聞いたことがないのですが。Javaが10年やってきて、これがベストプラクティスなら他の言語にも存在してもよいはず。なぜ使わないんだろう。。。ということで、例外を再考してみました。 例外をめぐる議論 何気にいろいろ調べていたら、こういうのがでてきました。2004年以降はRTE使っているよというのがこれか！？ Javaの理論と実践: 例外をめぐる議論 これはもう過去にされていた議論ですね。知らなかったですw Sunは、文書化されない例外は投げるべきでない。つまるところ、扱う例外はメソッドのthrowsにちゃんと明記する派。APIを使う側のユーザとし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外設計における大罪 - 契約
Wayang88 - LINK VIP RESMI LOGIN JOIN AGUSTUS 2024