なんだ、try{}catch{}で遅いループを速くするバッドノウハウも知らんのか。ショボｗIE5が出て程なく発見した俺より15年遅れている。

>>743
何もしなくてもコンソールにエラー内容が該当行と共に表示されるんだけどね
コンソールは誰でも見てる

>>734
> じゃあ、バグはどうする？
それは「自分で書いたコードのエラー」
仕様から読みとるのは「native関数のエラー」

あなたが言及した新機能APIへの対策は後者
一つの問題(後者)の話を棚に上げて、新しい問題(前者)を持ってくるべきではない

>>741
bar() でエラーを発生させるなら foo() で改めてエラーを発生させる必要はない
エラーの所在をはっきりさせないからこんなコードになる
foo, bar の要求仕様が確立されていれば、「foo で発生させるエラー」と「bar で発生させるエラー」は明確に区別されるはずだ
Array.prototype.forEach と Array.prototype.filter を組み合せた時、各メソッドで「同時に同じエラーが発生する」ことはないのと同じ

結局、このスレの総意はtry-catch使うなってことでいいの？
あと本当のエラーって抽象的な言い方じゃなく具体的なコード出して示してみろよ

全てのコードをtry-catchで囲って「はい、全てのエラーに対応したよー」っていうやり方が馬鹿だってことでしょ
try-catch自体は否定されてないように思うが

全てのコードってどういうこと？
具体的なコード示してみてよ

>>743のコードのこと。

相変わらずこのスレの馬鹿乙合戦は物凄い勉強になる

なんか反論（エラーを戻り値で返すときの素晴らしい方法）を
書いているかと思えばやっぱりソースコードを書いたのは俺だけだったね。
使えねぇな。

>>754
まず最初に修正したソースコード書いてね。

>>758
それはbuz()でどんな処理をしてるかで決まるんじゃ・・・
ちゃんと自分自身のコード出してよ
try-catch使わないコードも一緒にね

>>755
> 結局、このスレの総意はtry-catch使うなってことでいいの？

いや、なんのために、try-catchが言語仕様としてあるのかとｗ

昔、例えばC言語にはないんだよ。
それで苦労した歴史がある。

新しい言語には漏れ無く、try-catch相当の仕様が言語にある。
try-catchは何のための機能か？当然エラー処理のためだよ。

エラー処理専用の言語仕様が、新しい言語には漏れ無く付いている。
それはこの機能が極めて有効だってことを意味するんだよ。

>>762
ちゃんと書いてほしいよね。

エラーを戻り値で、つまりエラーコードで返す場合。
俺はすごく疑問なんだ。


数値を返す関数の内部でエラーが起きた時、
一体、何を返すのか？
NaN？ null？ undefined？

しかしこれではエラーコードは返せない。
詳細な理由はわからない。
さては文字列を返すのか？

しかし、今度は文字列を返す関数でエラーが起きたらどうするのか？
今度は、エラーコードを返すのか？

エラーの値が統一されていない。
関数によって、エラー処理の方法を変えるのか？

どれだけ大変なことをしているんだろう。

実際に書いているコードを見てみたいんだよね。

ちなみに、コンシューマーゲーム機のゲームはほぼ全部C++で作られてるけど
コンパイラの例外処理と実行時方情報(RTTI)はデフォオフられてる

さらにSDKの全APIは厳密にエラーコードが定義されてるが、それを戻り値で返す
例外を返すAPIは全く無いし、例外処理(try-catch)を遣ってるゲームも皆無だろう

ゲームに突然例外が発生しましたはありえない
ありとあらゆる状況で正しく動作する事が前提で、全てのSDKのAPIは
基本的に戻り値をチェックしてエラーが返ったら何らかの対処をする必要がある

>>762
＞それはbuz()でどんな処理をしてるかで決まるんじゃ・・・
あれ、>>743は汎用的なエラー処理の方法として書いたんじゃなかったのか？
buz()の処理内容次第では>>743が使えなくなるのなら、>>743はどういう意図で書いたんだ？

突然コンシューマ機の例を持ってくる馬鹿がいてワラタ
JavaScriptは特定の環境だけで動作するものなんですかねえ？

>>765
> ちなみに、コンシューマーゲーム機のゲームはほぼ全部C++で作られてるけど
> コンパイラの例外処理と実行時方情報(RTTI)はデフォオフられてる

うん。知ってる。らしいね。
理由は、究極的に速度が必要だから。

で、このスレの内容には当てはまらない
例外の話なんで、消えてくんない？

>>766
> buz()の処理内容次第では>>743が使えなくなるのなら、>>743はどういう意図で書いたんだ？

baz()の処理内容で使えなくなるのは、>>741だよ。

もしbazがが新たにエラーコードを追加した。ERROR_CODE3ね。
そしたらbarはそのままでは使えなくなる。

barを修正すればいいけど、あぁ大変だ。

さて、ERROR_CODE3を追加するだけならまだ楽だ。

もしbazの中で新たに、そうだね例えばlocalStrorageを使って
キャッシュさせる処理を実装したとしよう。そうすると、bazは例外を出すようになる。
例外を使ったコードにしていれば楽だが、今は戻り値でエラーを返す場合の話だ。

localStorageのエラーをERROR_CODE4として追加するのか？
localStorageがだすQUOTA_EXCEEDED_ERRというエラーをERROR_CODE4とし、
その他のエラーは・・・あぁ、調べるのが面倒くさい。だが戻り値で返すならば全部調べないとな！がんばれよ！

エラーコードだけならまだいい。エラーメッセージはどうしよう。
localStorageは"An attempt was made to add something to storage that exceeded the quota." という
エラーメッセージを例外オブジェクトの中に入れてくれる。

しかし、エラーを戻り値で戻すならエラーコードしか戻せない。
さてどうしよう。

baz()の処理内容次第で>>741だとどんどん悩みが増えていく。

まあさ、>>743と全く同じ動きをするコードを
戻り値で返したらどうなるかを書けば、
どれだけ、戻り値でエラーを返すコードが冗長になるかわかるよね。

>>741は>>743と全く同じコードではない。
手抜きをしたのに>>741だ。


反論したいなら、>>743と同じ動きをするコードを
例外を使わずに書いてみれば良い。

そのコードが>>743とほぼ同じ行数でかけたら感心するよ。
（もちろん行数稼ぐために;で無理やりつなぐのは無しｗ）

>>766
はやくコード出せよ

>>770
うーん言いたいことは分かったけど、それって単に>>743はエラー対応してないから短いだけじゃないの？
catchするだけcatchして、それからどうするの？って話。
むしろ個々に対応したエラー処理を省いている分、手抜きしてるのは>>743の方じゃないのか。

>>745でも指摘があるように、エラーメッセージを出すだけの目的なら、try-catchで囲まずに例外をコンソールに吐き出すのと大差ない。
エラーコードを吐く方法がいつもいいとは言わないけど、>>743が最善とはとても思えない

>>771
俺が言いたいのは、全てのエラーを>>743の方法で片付けるのがおかしいっていうこと。
万能なエラー対応方法はないから、コードの提示のしようがない。
例題を出してくれたらいくらでも答えるけど。

JavaScriptでは非同期処理が多用されるわけだけど、
それの異常系もtry/catchでなんとかなると思っているんだろうか

>>773
だから、お前の思う最善の例を出してみろって。
それが出来ないなら単なる戯言でしかないからもうレスすんな

>>775
戯言に反論できないからと言ってムキになるなよ

>>776
あーやっぱりコード出せないのか
馬鹿はもうレスしなくていいよ

>>777
馬鹿に反論できなくて悔しいのは分かった

>>778
まずお前が理解できてるか確認する為に、具体的なコードを出してみ？
そしたらいくらでも反論してやるよ
馬鹿だからどうせ出せないんだろうけど

>>779
さっきも言ったけど、>>743のような万能な対応方法はないというのが主張だから、例を挙げてもしょうがないと思うが…

document.getElementById("hoge").style.color = "red";
このコード、もし#hogeが存在しない場合、try-catchで捕捉できる。でも、いつもそれが正しいと言える？

こうしたい時だってあるはず
var elm = document.getElementById("hoge");
if(!elm){ /* #hogeが存在しないことに対する対応。#hogeを作成するなりなんなり。本当に例外にしたいならthrowする */ }
elm.style.color = "red";

あとは>>774のいうように、setTimeoutやXMLHttpRequestなど、非同期のものはtry-catchでは対応できない。

「未知のエラー」はどこへいった？
>>743では「未知のエラー」に対応できてないんだが、どんなエラーでも対応できる汎用的な方法じゃなかったのか？
コンソールデバッグと何もかわらんではないか

全体をtry～catchで囲うことへの反論は>>744>>745>>748>>749>>752にもあるぞ
スルーすんなよ

そもそも、>>741と>>743では比較対象にならない
>>741はユーザ定義のエラー処理だが、>>743はただの例外処理(ユーザ定義のエラー処理がない)
比較するなら、>>743と「>>743からtry-catchを削除したコード」だろう

>>732-733,735にも返答が欲しいところだな
将来的な仕様変更に>>743では対応できてない事だしな

>>768
速度も重要だが
> ゲームに突然例外が発生しましたはありえない
という方が重要

全てのエラーを捕捉して対処する事に意味がある
try-catchを使ったからと言って簡単になるわけではない
↓これをtry-catchで簡単にしてみて (hoge()やhage()が例外を投げる前提)
var res = hoge();
if (res >= 0) {
// 成功
} else {
// なんらかのエラー
switch (res) {
case -1:
// なんらかのエラー処理1
break;
case -2:
// なんらかのエラー処理2
break;
case -3:
// なんらかのエラー処理3
break;
default:
// 未知のエラーの為の処理
break;
}
error(); // 共通のエラー処理
return errorCode;
}
var res = hage();
// 以下同じような処理が続く

>>729
> 未知のエラーは、どこまで調査すれば無くなる？
逆に聞きますが、仕様書を読んで「既知のエラー」にする対策はとらないのですか？
しないとしたらそれはなぜですか？

最初JSONの破損チェックの話じゃなかったっけ

(o.a.b.c.d.e.f.g.h.i.j.k.l.m.n == 1)
このテストで
アホみたいに先頭から順番にif文で確認するのもいいけど

try{
　if(o.a.b.c.d.e.f.g.h.i.j.k.l.m.n == 1){
　}
}catch(){
}
全部囲めば楽だよねって話

>>788
> 最初JSONの破損チェックの話じゃなかったっけ
>>693はそんな話はしてない

>>788
それのどこが未知のエラー？
知らないなら ES5 仕様書を読んでくるといいと思うよ

>>789
そんな話と思うけど>>690

もうjavascript関係無いな、いつの時代の議論だよって感じ

try～catchやエラーコードに関するコードを書かないのは、もう何十年も議論され尽くされててちょっと探せば沢山コードなんて見つかるのに、今更「ソースまだぁ？」とか言う勉強不足野郎に呆れてみんな書かないんじゃないの？少なくても俺はそうだ

try～catchの誕生した背景と解決しようとした課題、そして新たに出てきた問題とか色々引っくるめて結論だけ言うと

「適材適所で使い分けろ」

だ。銀の弾丸なんで存在しない。コードが短くなるから～とかスビードガァとか、そんな短絡的な理由でどっちが優れてる！使うべき！とか、レベル低すぎるんだよ

>>780
> document.getElementById("hoge").style.color = "red";
> このコード、もし#hogeが存在しない場合、try-catchで捕捉できる。でも、いつもそれが正しいと言える？

正しいじゃんか。

このコードは、#hogeが存在しないことはありえないってことだろ？
アプリの仕様として#hogeが存在しないことはありえないなら、
こういうコードを書いていいし、
ありえないことが起こってしまった場合（おそらくバグだろう）
それはエラーになるべきだ。

それこそが、未知のエラーよ。

こういう未知のエラーに対して汎用的なコードを用意しておけば
ユーザーのシステムエラーが起きたことを通知したりログをとったり出来る。

> こうしたい時だってあるはず
> var elm = document.getElementById("hoge");
> if(!elm){ /* #hogeが存在しないことに対する対応。#hogeを作成するなりなんなり。本当に例外にしたいならthrowする */ }

これは意味が変わってる。アプリの仕様として
#hogeが存在しない場合がありえるときにこう書く。

>>780
> あとは>>774のいうように、setTimeoutやXMLHttpRequestなど、非同期のものはtry-catchでは対応できない。

じゃあ、戻り値でエラーを返す方式なら対応できるんですかー？

非同期のものは処理が開始されるタイミングが違うだけ。
その中でtry-catchをするんだよ。
どうせ戻り値でエラーを返してもそうするだろ？

「処理が開始されるタイミングが違う」という両方とも同じことに対して
try-catchだけの問題みたいにいうな。

>>786
お前、設計がおかしい。

そもそもエラー毎に個別のエラー処理が必要になることはまず無い。
そのの処理はこうなる。

try {
　var res = hoge();
　var res = hage();
} catch(e) {
　共通のエラー処理
　throw e; // エラー再送信
}

その上で重要なのは、例外は深い階層から一気に
上の層まで処理を飛ばせること。
発生したエラーを画面にalertでだすか、
console.logにだすか、サーバー側に通知するかはアプリ次第。
どうするかは、一箇所にまとめるべき。それがonerror

もし上の処理が、foo -> bar -> baz の中の処理だった場合、戻り値でどうやって処理を中断させるのか？

もし上の処理が、foo -> bar -> baz の中の処理だった場合、戻り値でどうやって処理を中断させるのか？

function foo() {
　bar();
　// 正常時の処理
}

function bar() {
　baz();
　// 正常時の処理
}

function baz() {
　var res = hoge();
　var res = hage();
　// 正常時の処理
}


もしどこかでエラーが起きた場合、例外であればちゃんとそこで
returnしたような動きに出来る。

これを戻り値で書くとこうなる。大変だよなぁｗ

function foo() {
　if (!bar()) {
　　return;
　}
　// 正常時の処理
}

function bar() {
　if (!baz()) {
　　return;
　}
　// 正常時の処理
}

function baz() {
　var res = hoge();
　if(!res) {
　　return;
　}
　var res = hage();
　if(!res) {
　　return;
　}
　// 正常時の処理
}

ほら、戻りを使うと、もうコードが倍になっちゃうｗ

>>793
エラーのログを取るのが目的だったのか？>>743はエラーに対応する万能の方法じゃないのか？

>>795
>>795
＞そもそもエラー毎に個別のエラー処理が必要になることはまず無い。
それはお前の思い込みだ
もしこの考えを変えないのなら、お前と議論する意味はない

>>797
なぜ「例外がある⇒returnで中断すれば問題ない」という短絡的な思考になれる？

例外野郎は>>792を100回読んどけ
はっきり言ってこの言い争いは低レベルすぎるし無駄だ

>>791
何も破損してないだろう？
>>693は a が配列ではなかったら null が入るといっている
であれば、下記コードで事足りる

if (a) { }
　又は
if (Array.isArray(a)) { }

どういう処理をしたいのか知らないが、処理を停止させたいなら TypeError を発生させるのも一つの手段

中身が薄くてレベル低すぎだろ

いい加減放置しろよ、795は引っ込みつかなくなって自分が正しいと証明したいだけの自己愛性パーソナル障害