トップページ > プログラム > 2015年01月05日 > xBMPeqox

書き込み順位&時間帯一覧

7 位/216 ID中時間01234567891011121314151617181920212223Total
書き込み数0000000000000000000030047



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
【node.js】サーバサイドjavascript 3【io.js】©2ch.net

書き込みレス一覧

【node.js】サーバサイドjavascript 3【io.js】©2ch.net
57 :デフォルトの名無しさん[sage]:2015/01/05(月) 20:40:46.70 ID:xBMPeqox
>56
> ただし、本当に内部の実装がそうなってるかどうかはお前が確認して報告しろ

process.nextTick()もsetImmediate()もsetTimeout()もそうなってるよ
どの関数もreturnして後続のコードが実行されてイベントループに戻るより前に
コールバックが呼ばれることはない

> > Chrome開発版や他のブラウザだとブレークするのか?
> 通常のChromeとFirefoxでブレークするのを確認した

>>54が引用されてるが、それはお前の言う「ハンドリングしてない予期しない例外」
とは別の「ハンドリングしてないreject」の話だぞ
>>54の一行目にそう書いてあるだろ

それより

> まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが
> 気を効かせて例外を通知してくれるって事を言ってんのに

について具体的にコードでも書いて説明してくれよ
日本語じゃまともに通じてないんだからその方がお互い手っ取り早いだろ?
【node.js】サーバサイドjavascript 3【io.js】©2ch.net
58 :デフォルトの名無しさん[sage]:2015/01/05(月) 20:47:12.39 ID:xBMPeqox
これは「ハンドリングしてないreject」としてのレス

>>56
> 通常のChromeとFirefoxでブレークするのを確認した

まずは確認だが、Chromeで"Pause On Caught Exceptions"は外してるよな?
あれはハンドリング「してる」例外でもブレークするからここでは邪魔になる
その上で、rejectをハンドリングしている

Promise.resolve(true).then(function(v) {
 throw new Error('then');
}).catch(function(e) {
 console.log(e);
});

はブレークしないが、rejectをハンドリングしていない

Promise.resolve(true).then(function(v) {
 throw new Error('then');
});

はブレークするのを確認した、ということで間違いないか?

俺のChrome 39ではどちらもブレークしない
(通常の「ハンドリングしてない例外」はもちろんブレークする)
もしChromeの設定が必要なら教えて欲しい
【node.js】サーバサイドjavascript 3【io.js】©2ch.net
59 :デフォルトの名無しさん[sage]:2015/01/05(月) 20:56:09.22 ID:xBMPeqox
これも「ハンドリングしてないreject」としてのレス
例外ではなくrejectの話ということがより明確になるようにコードを修正した

rejectをハンドリングしている

Promise.resolve(true).then(function(v) {
 return Promise.reject(new Error('then'));
}).catch(function(e) {
 console.log(e);
});

はブレークしないが、rejectをハンドリングしていない

Promise.resolve(true).then(function(v) {
 return Promise.reject(new Error('then'));
});

はブレークするのか?

ちなみにQを使う場合はQ.getUnhandledReasons()で
「ハンドリングしてないreject」の一覧を取得できる
nodeではsetInterval()で定期的にログ出力すればデバッガの必要性は低い
【node.js】サーバサイドjavascript 3【io.js】©2ch.net
62 :デフォルトの名無しさん[sage]:2015/01/05(月) 23:31:48.05 ID:xBMPeqox
>>60
> 調べもせずに適当な事言うなよ

調べて言ってるけど?
まずは仕様

https://html.spec.whatwg.org/multipage/webappapis.html#timers

"timer initialisation steps"の10で"Return handle, and then continue running this algorithm in parallel."
となっていて、コールバックが呼び出されるのは14の"Queue the task task."によってだ
そしてNodeの実装

https://github.com/joyent/node/blob/v0.10/lib/timers.js#L194

203行目でTimeoutオブジェクトを作って225行目でactive()に渡してる
175行目からのactive()はリストにTimeoutオブジェクトを追加してるだけ
どうやってもsetTimeout()がreturnする前にコールバックが呼ばれることはない

> 少なくともsetTimeout()は絶対違う

その根拠は? お前は主張するばっかで根拠は何も示さないのな

>>61
> 捕捉するがタイムアウト時間を1msとかにすれば、99.9%実用上問題無いだろう
> だが「確実」に非同期にするという事とは全く意味が違う

お前「非同期」の意味わかってる? タイムアウト時間は非同期とは一切関係ないぞ
setTimeout()は常にコールバックを非同期に実行する
ただしコールバックが実行されるまでの時間は指定したとおりになるとは限らないだけだ
特にネストした呼び出しでは0〜3msを指定しても最低4msは待たされる(上の仕様に書いてある)
だが常に非同期だ
【node.js】サーバサイドjavascript 3【io.js】©2ch.net
63 :デフォルトの名無しさん[sage]:2015/01/05(月) 23:36:20.18 ID:xBMPeqox
>>60
> 他は日本語が意味不明

お互いになw でもJSのコードは分かっただろ?
だからお前が言いたいこともコードで示してくれって何度も言ってるわけだ
なんでコードで書かないんだ?

> Promise.resolve(true).then(function(v) {
>  throw new Error('then'); ← ここでデバッガがブレークする
> });

それだけだと"Pause On Caught Exceptions"を有効にしてるようにしか見えないな
その場合ブレークするのは内蔵Promise一切関係ないからな
catch()してるケースではどうなんだ? ブレークしちゃうんじゃねーの?
>>59のPromise.reject()版でもブレークするのか? しないんじゃねーの?

> アホなお前はこれでも理解出来ないと思うが、俺はこれ以上説明しない

それこそ負け惜しみだろw
「しない」じゃなくて「できない」んじゃねーの?

> > nodeではsetInterval()で定期的にログ出力すればデバッガの必要性は低い
> 糞みたいな負け惜しみすんなよw

繰り返すけどここはサーバサイドJSスレなんでな
動かしっぱなしのサーバではロギングして調べる方が基本なんだよ
ぶっちゃけこのスレでもNodeでデバッガ普段使いしてるヤツの方が少数派じゃね?
他の人どうよ?
【node.js】サーバサイドjavascript 3【io.js】©2ch.net
64 :デフォルトの名無しさん[sage]:2015/01/05(月) 23:38:49.17 ID:xBMPeqox
>>61
> デバッガのデフォ設定では飲み込まれて無反応だ
> さんざんケチつけてる割にはそんな簡単な設定も分からんか

わからんな
頼むから教えてくれよ
煽るより少ない文字数で終了するだろ

> ただ、激しくスレチな事なんで無理もないからそろそろ黙ってくれ

何を今更w
>>55とか他の人も興味あるかもしれないだろ
そんな簡単な設定ならさっさと書いてくれよ
【node.js】サーバサイドjavascript 3【io.js】©2ch.net
67 :デフォルトの名無しさん[sage]:2015/01/05(月) 23:59:55.31 ID:xBMPeqox
>>65
> いつ実行されるか保証してないじゃん

それ俺が書いた

> ただしコールバックが実行されるまでの時間は指定したとおりになるとは限らないだけだ

のことな

> 上の方のa += 1;を実行するまでに100msの時間が掛かったとすると、その前に実行される可能性がある

その可能性はないんだよ
ステップの10でリターンした「後」、残りのステップは並列に実行される可能性がある
その一つのステップ14でコールバックを実行するタスクがキューに入れられる
タスクはキューに入れられるだけで実行はされない
そしてそのタスクがキューから取り出されて実行されるのは制御がイベントループに戻った後だ
お前の言うa += 1;の実行が終わらない限り制御がイベントループに戻ることはない
だからsetTimeout()はタイムアウト時間に一切関係なく常に非同期だ
詳細は"14. Queue the task task."のリンク先を見てくれ

そんな難しく考えなくてもシングルスレッドなんだからわかりそうなもんだがw


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。