立場についても話していけるといいと思う。変換してくれるユーティリティメソッド。下記のような要領で変換できる。コアメソッドに限らず、他のメソッドもPromiseに変換できる、ただし、変換する場合はその関数がpromisifyの規約に従っている必要がある。対象になってしまうことがある。コアメソッドのほとんどは上記の規約に従ったコールバック関数を取るが、Node.jsの規約から外れたコールバックの使い方をしているメソッドの場合は一工夫が必要になる。場合がそうなる、これらはコールバック関数を最初の引数に要求するし、コールバック関数の最初の引数はエラーとは限らない。プロパティにしてカスタマイズされたPromisify関数を提供してあげる必要がある。使ってcustomizeされたPromisifyを作っている。中では実はまだまだ議論の余地がある。採用するかどうかを議論していた時にその場に居たので、要点をまとめるとunhandledRejectionの時の振る舞いが決まっていないという一点につきる。いなかっただけであり、Promiseが例外をキャッチするのは仕様上いつでも良いので、この時点で出るwarningsとしては適切ではない(非同期にキャッチされる可能性があるため)。使ったとして、例外をキャッチしなかった際に容易にメモリリークやファイルディスクリプタのリークが起きることは想像しやすく、やはりNodeコアの中でも簡単にリークが作り込めてしまうような状況にするべきではない、リークが気づきにくくなる位なら異常終了した方がマシというのが議論ポイントだった。安全に使える手段として提供してあげる(リークを起こさないようにする)べき』という感じだろうか。動きで既に3,4候補存在する。(https://github.com/nodejs/node/pull/6355)まだこの部分の議論は続いている。追加する件に関してはある程度の有用性、コアでやることの意義が認められてマージされた。使いやすくなってきているが、まだまだ運用面での知見が少ないという点だと思う。気をつけて使うべきだろう。Promiseを使ってしまうとエラーになって死んだ時に解析がしにくいという側面もある。www.joyent.comutil.promisifyができたことで、Promiseが使いやすくなっているが、この辺りはまだ仕様検討中なのでv8.0次第ではPromiseの使い勝手は変わる可能性もある。Promiseを無限ループさせるとリークが起きるというのは仕様の問題であって、Node.jsの問題ではありませんでした。(2)リンクヘルプはてなブログお知らせはてなブログをはじめよう!yosuke_furukawaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。