[過去ﾛｸﾞ] 【node.js】サーバサイドjavascript 3【io.js】©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
18(3): 2015/01/04(日)00:06 ID:NffMCEWR(1/14) AAS
その程度は自前でも並列と逐次の小さなヘルパ関数を用意するだけで十分きれいに書けるだろ
実際はそんなもん自前で書かずにasync使ってたけどな
ECMA標準だから仕事じゃPromise使ってくけどそんなのは所詮表層の話に過ぎないよ
PromiseよりStreamが適することも多いし
22(2): 2015/01/04(日)00:35 ID:NffMCEWR(2/14) AAS
>>19
どこを誤読するとそうなるんだよwww
並列ってのはPromise.all()やasyncのparallel()のような処理フローのこと
逐次ってのはPromiseのthen()によるチェーンやasyncのseries()・waterfall()のような処理フローのこと
俺の方はスレの流れを読めてると思うぞ
25(2): 2015/01/04(日)00:54 ID:NffMCEWR(3/14) AAS
>>21
サーバサイドJSスレで「ブラウザ内蔵のPromise」ってw
そこはv8のPromise実装って書けよ
>>22
QとかBlurbirdはそれらをJSで実装してるわけだからな
どうしてJSで実装できないと思い込んだのか謎だ
26: 2015/01/04(日)00:56 ID:NffMCEWR(4/14) AAS
安価ミス、>>25の後半は>>23へのレス
あとBlurbirdじゃなくてBluebird
28(1): 2015/01/04(日)01:21 ID:NffMCEWR(5/14) AAS
>>27
「お茶を濁してる」について詳しく
nodeではprocess.nextTick()かsetImmediate()で確実に非同期にできるが？
v8のPromiseだってマイクロタスクキューに入れられて結局はnodeのイベントループで処理されるのは同じ
例外のデバッグって具体的には？
Promise.catch()にブレークポイント付けれるって話？(それはブラウザ関係ないと思うが…？)
もしそうならライブラリがcatchした例外はコールバックの第1引数に渡されるのがnodeの流儀で同じようにできるが？
29: 2015/01/04(日)01:41 ID:NffMCEWR(6/14) AAS
で、>>19は>>18を誤読してたってことでいいのか？ >>22を読んだ上での反論は？
31(2): 2015/01/04(日)02:35 ID:NffMCEWR(7/14) AAS
>>30
> それがJavaScriptで実装出来ない事をしてることじゃなくて？
nodeではv8のマイクロタスクキューもsetImmediate()もnodeのイベントループで処理されるのは同じって意味な
つまりJSのsetImmediate()でコールバックを確実に非同期にできるってこと
これはブラウザでも同じはずだ
違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ
> 呼び出し側に例外が来ないって事だ (当たり前の事だけど)
ライブラリの実装依存ではあるが、nodeでは当たり前じゃない
nodeでは例外を第1引数としてコールバックすることで呼び出し側に例外を伝えるのが流儀だ
だからPromiseでnodeのAPIやライブラリをラップしてもPromise.catch()に例外が渡る
(ラッパーはコールバックの第1引数に例外が渡されたらPromise.reject()を呼び出す)
>>21を見てから薄々じゃなく確信していた
33(2): 2015/01/04(日)03:42 ID:NffMCEWR(8/14) AAS
>>32
> これが実行される前にcallbackが絶対実行されない
ことを保証してんの？
仕様はそうなってる
外部ﾘﾝｸ[html]:dvcs.w3.org
> そもそも非標準のAPIなんだけど…
そこはこのNotesに書いてある"platform code"から好きなものに置き換えてくれ
外部ﾘﾝｸ:github.com
> QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか…
>>23（これは俺とは別人）からは「それPromise使わなくてもできるよ」って話をしてるな
それは当然JSで書かれたQやBluebirdでもできるってことだから元の話と違ってるわけではない、スコープが広がっただけ
で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？
42: 2015/01/04(日)17:40 ID:NffMCEWR(9/14) AAS
>>37-38
技術的に難しい話はしてないが、こういう場で会話を成立させるのは難しいなw
できれば誰か ID:kuXg+7pG の主張を翻訳して欲しい
43(2): 2015/01/04(日)18:06 ID:NffMCEWR(10/14) AAS
>>34
> a += 1;の実行が終わってからとは言ってないと思うが
"5 Processing Model"の4に、5以降は非同期に実行すると書いてある
> 置き換えて何だよ？
お前が使ってるブラウザに合わせて読み替えろというだけだ
サーバサイドJSスレとしてはnodeで使えるprocess.nextTick()やsetImmediate()で何の問題もない
> platform code(要するにJavaScriptでないコード)を実行しろとわざわざ書いてる
"paltform code"はプラットフォームごとに異なるコードという意味で
それがJSで実装されてようがされてまいがどうでもいい
実のところnodeのsetImmediate()はJSで実装されている
外部ﾘﾝｸ[js]:github.com
> > 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ
> 元の質問は↑これ、お前は論点をずらそうとしてるだけだな
いみふ
「ブラウザが内部で実装しないと無理」の対象はPromiseそのものの実装だ
Promiseの実装が呼び出すAPIの話じゃない
「stringはブラウザで実装されている」を理由に「stringを使うのはブラウザが内部で実装しないと無理」っておかしいだろ？
"platform code"がブラウザやnodeで実装されていても、それを使うコードはJSで書ける
たとえばQはこの辺で"platform code"を呼び分けてる (モダンブラウザだとpostMessage()が使われてるな)
外部ﾘﾝｸ[js]:github.com
これは「ブラウザが内部で実装しないと無理」ではなく普通のJSのコードだ
44(3): 2015/01/04(日)18:08 ID:NffMCEWR(11/14) AAS
>>34
> >>30の下の方で言ってるよ
話がループしてるな… その>>30の以下について
> Promiseに限った話しじゃないが、ライブラリ内でtry,catchしちゃってると
> 呼び出し側に例外が来ないって事だ (当たり前の事だけど)
これはPromiseを実装するQのようなライブラリ側の話だよな？
ライブラリ側がcatchした例外を飲み込んで捨てた場合は確かにそうだが、
QやBluebirdは飲み込まずにPromise.catch()に通知するだろ
Promiseを使わない場合でもnodeの流儀ならコールバックの第1引数で通知する
だからこれは「ブラウザ内蔵のPromiseはJavaScriptで実装出来ない事をしてる」に該当しない
っていうのが>>31で書いたことだ
それに対して>>32で
> QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか…
と返されたわけだが、前述の通り飲み込まずにPromise.catch()で通知されるはずだから
そうじゃないっていうなら
> で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？
と>>33で尋ねたわけだ
その返事が>>34の「>>30の下の方で言ってるよ」だと完全にループ
まずは確認だが、
・QとかBluebirdでは例外が飲まれる
って主張してるんだよな？
それならどういうケースでそうなるのか例を示してくれ
Promise.catch()に伝わらないケースがもしあるなら、おそらくそれはただのバグだ
52(1): 2015/01/04(日)22:08 ID:NffMCEWR(12/14) AAS
暇ならもう少し相手してもらおうか
まず
> ・渡されたコールバックを確実に非同期で実行する
これがJSで実装できないって主張は間違いだったということでいいのか？
次に
> ・飲み込まれた例外をデバッグ出来る
「まったくハンドリングしてない予期しない例外」をデバッグできるのは内蔵Promise関係なく
JS処理系(Chromeならv8)のデバッガの機能だろ
nodeでもv8のデバッガは有効だからnode debug x.jsで実行してbreakOnExceptionしておけば
「まったくハンドリングしてない予期しない例外」でブレークする
nodeはprocess.on('uncaughtException')があるからそれでデバッガ使う機会は少ないけどな
だがこの話マジでPromise関係なくね？
つか「ハンドリングしてない例外」でなく「ハンドリングしてないreject (uncaught promise rejections)」
のデバッグを言ってるのか？
だとすると全然話が違うが、debugger文を使えば内蔵Promiseじゃなくても実装はできるな
> お前はなんで分かんないんだよマジで無能だな
お前以外誰もお前の言ってることを理解できてないんじゃないか？w
できてる人がいるならマジで翻訳してくれ
あと俺はECMA入り前を含めると2012年頃からPromise使ってる
ただしnodeでの話だからブラウザ固有の話は知らない可能性は高い
ここはサーバサイドJSスレなんだからその辺はお前の方が考慮してくれ
53: 2015/01/04(日)22:36 ID:NffMCEWR(13/14) AAS
せっかくなので具体的に
こういうコード(x.js)があるとするじゃろ
process.nextTick(function() {
throw new Error('unhandle');
});
こうやって実行するじゃろ
$ node debug x.js
< Debugger listening on port 5858
connecting to port 5858... ok
break in x.js:1
> 1 process.nextTick(function() {
2 throw new Error('unhandle');
3 });
1行目で止まってるからおまじないを唱えるじゃろ
debug> breakOnException
実行再開するじゃろ
debug> c
exception in x.js:2
Error: unhandle
1 process.nextTick(function() {
> 2 throw new Error('unhandle');
3 });
debug>
ハンドルされてない例外のせいで2行目で止まったじゃろ
54(1): 2015/01/04(日)23:45 ID:NffMCEWR(14/14) AAS
ところで「ハンドリングしてないreject」のデバッグって
最新のブラウザではサポートされてるのか？
たとえば
Promise.resolve(true).then(function(v) {
throw new Error('then');
}).catch(function(e) {
console.log(e);
});
と最後にcatch()すべきところを忘れてしまって
Promise.resolve(true).then(function(v) {
throw new Error('then');
});
とした場合、これをChrome安定版(39)で実行してもブレークしない
スローした例外は内蔵Promiseの実装でcatchしてるからv8から見ると
ハンドルされてるって扱いなんだろう
Chrome開発版や他のブラウザだとブレークするのか？
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.043s