>>700
いや、違う。throwすることで戻り値を使わずに
コールスタックを登らせることが出来るんだよ。

一番面倒なのが「戻り値を返す関数」の中でエラーが出た場合
それをどうやって戻り値の中に混ぜ込むか、
混ぜ込んだ戻り値の中からどうやってエラーを判別するか。
そのためのコードを書くのが面倒。

例外を使えば、そのことを一切考える必要がなくなるし、
エラーをログに出力する場合でも、windowのonerrorが利用できるようになる。

だから特殊な処理をしたい時だけ対応コードを書けば良くなる。
逆に言えば、ほとんどの対応不可能なエラーに対して、
書かなければならなかったコードが大幅に減る。

>>694
正しくても正しくなくてもHTTPコードが同じでJSONを受け取るものとお考えください

>>702
正しくても正しくなくてもJSONを受け取るというのなら
そのようにコードを書いて下さい

json = fixJson(json);

>>701
> だから特殊な処理をしたい時だけ対応コードを書けば良くなる。
> 逆に言えば、ほとんどの対応不可能なエラーに対して、
> 書かなければならなかったコードが大幅に減る。
それはtry-catchの使用に関わらず一般論だ

関数内のどこでどんなエラーが発生したかを記録してエラーコードに含めて
なおかつ後処理もする事を考えると、try-catchを使わないと作りが悪くなる
本質的な理由が分からん

未知のエラーを上にぶん投げたいだけだろ

> 未知のエラーを上にぶん投げたいだけだろ

それが重要なんだって、

既知かつ対応可能なエラーは数が少ない。
それに対して未知は、未知なんだから無限にありえる。
だから未知のエラーに対応するのは不可能
（せいぜいメッセージを出してログに記録するだけ）

そんなことをしているから、
エラーチェックとエラー処理の方がコード量が多い
なんてことになるわけ

それに関数内のどこでどんなエラーが発生したかなんて
例外を使っていれば、自動的に記録される

>>703
ということでa != null && a[1] == 1とかいたんですがもっといい書き方ありますか？

>>706
a[1] == 1 こう書けばいいよ。

aにnullが入ることはない。
そのように作りなさい

そしてふりだしに戻る

たぶん、一行で書く俺頭いいって思ってるんだと思うね。

不正なJSONデータを直したいのなら先に直しておくべきで、
正常でも不正でも扱えるコードを書こうとか考えるほうがおかしい。

>>706
a && a[1] == 1 でOK

>>710
それだと、aがnullのとき、a[1]に1が入らない。

> 正しくても正しくなくてもHTTPコードが同じでJSONを受け取るものとお考えください
って書いたのをお忘れですか？

if (a === null) {
　return;
}
a[1] = 1

って書けばいいじゃん。

aにnullが入っているのに、そのまま処理を
続けようとするほうがおかしい。

>>690
JSONの仕様に対応できてないね
(a != null)は
a=trueでもa=1でもa="hoge"でも真だから不完全
try-catch使っとけばいいよ

>>711
誰が誰だかわからないけど、とにかく a に何か入ってることが確かなら a[1] == 1 だけでOK。

>>705
> それに対して未知は、未知なんだから無限にありえる。
アホかそんなわけない
考え方が根本的におかしかったんだな

>>705
> それに関数内のどこでどんなエラーが発生したかなんて
> 例外を使っていれば、自動的に記録される
デバッガ上でなくて本稼動してるのに自動で記録されるとは知らなかった
そして本稼動ではエラーを垂れ流すんだな

>>712
それ、a != null && a[1] == 1と同じ事じゃん

>>690
aの変数初期化処理でaに入りうる型が確定するのでその時点で処理すべきです

>>693
JSONパーサがデータを返す時点で分岐処理させて下さい
JSONパーサのが返しうる返り値、返り値として期待する型、[[]Class に依存します]
もし、JSONパーサの返り値で配列を期待するなら Array.isArray で配列とそれ以外を区別して下さい
そうでないなら、あなたの期待する処理を整理すべきでしょう

もうjavascriptの質問じゃないかもしれませんが
hoge.htmlを開いてなくてもブラウザさえ起動してれば動いて
hoge.htmlを開いた場合にはjavascriptの関数を実行したりする機能ってありますか？
chromeの拡張機能だけ、operaだけでしか動かないとか何でもいいので

hoge.html は自分のPCにあるの？それとも、ドメイン関係なく外部サイトの /hoge.html ?
ローカルにあるなら hoge.html に埋め込んで、onload で実行するようにできるし、後者なら greasemonkey を調べてみるといいかも。

>>717
無理やり一行で書くなって話だよ。

>>715
アホはお前だな。

プログラムっていうのはな、すべての行でエラーが
起こりえるという前提で作らないとだめ。

そんなの不可能と思っているならば、
お前が例外ではそれが可能だってことを知らないだけだ。

>>722
tryの行やcatchの中で起こりえるエラーにはどうやって対処するの？

そもそもtry～catchはそう言う目的で登場した訳ではないだろ、短く書けるとかは副作用

「未知のエラー」というのは調査してないからそう感じるのであって「既知のエラー」にすれば問題ない
全ての例外は仕様で規定されている為、入念な調査を行えば「既知のエラー」となる
よって、仕様を理解できれば例外が発生しないようにコーディングすることは可能
例外を catch しないと判定できない状況もありえない訳ではないが、そこまで多くはない為、try-catch を基本とする必要性は皆無

>>722
？？？
>>724と同じ事言ってるけど…

間違えた。。。
>>722
？？？
>>715と同じ事言ってるけど…

>>723
chrome　拡張機能　バックグラウンドページ

>>725
> 「未知のエラー」というのは調査してないからそう感じるのであって「既知のエラー」にすれば問題ない

未知のエラーは、どこまで調査すれば無くなる？
未知のエラーが無くなったことなんか調べようがない。
今はなくても、将来ライブラリやWEB APIの仕様で追加されるかもしれない。

だからまず、未知のエラーに対して処理する汎用的なコードを書く。
これが第一歩。

ただし、この未知のエラーに対するコードを、例外ではなく戻り値で管理すると、
戻り値はエラー専用になって、本来使いたい戻り値として使えなくなってしまう。
また、自動で上に投げられないから、手動で上の関数にreturnするコードを書かなくなってしまう。

つまり戻り値のやり方では、汎用的なエラー対策コードは書けないか
書いたらすごく大変なものになる。

戻り値でエラー処理をしようと思うから以下の様な発言になってしまうだよ。
> 本気でコード書いたらエラーチェックとエラー処理の方がコード量が多い事も普通

正しく例外を使えば、エラーチェックとエラー処理のコードは大きく減る。
対応の必要があるところだけ、対応すればいいからね。

>>729
全部込みのオブジェクト返せばいいよ
非同期対応のAPIもcallbackからオブジェクト帰ってくるじゃん

バックグラウンド機能ってクロームだけなんだろうか
あれすっげぇ便利なのに

>>729
> 未知のエラーは、どこまで調査すれば無くなる？
仕様書を見て仕様書通りに実装すればなくなる

>>729
> 今はなくても、将来ライブラリやWEB APIの仕様で追加されるかもしれない。
仕様はある時、突然勧告されるわけではない
勧告前の仕様もチェックするようにし、先行実装された実装でテストしておく
既存仕様との差異が既存コードに影響するようならそこで修正すればよい

> だからまず、未知のエラーに対して処理する汎用的なコードを書く。
どんな条件でどんなエラーが発生するかわからずして、対策コードは書けない し、時間の無駄

>>732
じゃあ、バグはどうする？
プログラムは一人で作るものじゃない。

誰かが作った部分にバグでエラーが発生した時、
バグなのだから当然仕様には明記されていない。

こういう場合にどうやって、エラーが起きたことを補足して
途中で中断するのさ？

>>733
> どんな条件でどんなエラーが発生するかわからずして、対策コードは書けない し、時間の無駄

書けるよ。簡単に。

時間の無駄だと思うのは、戻り値なんかで
エラー処理してるからだよ。

言葉じゃなんとでも言えるから、実際のコードで書いてみて欲しい

まあ、完全に答え出てるんだよね。

一方は、私のやり方ではエラー処理が大変で時間がかかって対応しきれません。って言ってる。
もう一方は、私のやり方ならエラー処理は簡単で未知も含めた全てのエラーに時間を書けずに対応できます。と言ってる。

>>729
全てを「未知のエラー」でひっくるめるようなら、それが下記のいずれかを区別出来てない事になるな

1. 仕様変更によるエラー
2. 元々、実装依存の挙動で特定の実装に依存するコードであった為のエラー
3. 特定の実装で未対応だった機能が有効化された事によるエラー

仕様を正しく理解してコードを書けば、将来的にも 2. と 3. によるエラーは発生しない
確認しなければならないのは 1. だけなので、コード修正は最小限で済む

>>736
そうだね。じゃあ書いてみようか。

関数が4つ有るとする。main()がfoo()を呼び、foo()がbar()を呼び、bar()がbaz()を呼ぶ

function main() {
　foo();
}

function foo() {
　bar();
}

function bar() {
　baz();
}

function baz() {
　・・・
}

これはエラー処理を書いていないコードだ

まず、以下の理由

> 本気でコード書いたらエラーチェックとエラー処理の方がコード量が多い事も普通

俺とっては、はぁ？ｗ だが、
まあ、例外を知らないやつはこう思っている奴が多い。

エラーをどう戻り値で返すか？ は関数によって違う。
例えば数値型を返す関数なら、nullやNaNを返すかもしれない。
内部で起こった詳細なエラーを、エラーコードで返すかもしれない。
まあ色々なわけだ。

じゃあ、戻り値でエラーを返すと、エラー処理のほうが多くなるという
実例をおみせしよう

function main() {
　if (foo() === null)
　　alert('エラーが発生しました');
　　return;
　}
}

function foo() {
　if (bar() < 0) {
　　alert('エラーが発生しました');
　　return null;
　}
}

function bar() {
　if (baz() === ERROR_CODE1) {
　　alert('エラー1が発生しました');
　　return -1;
　}
　if (baz() === ERROR_CODE2) {
　　alert('エラー2が発生しました');
　　return -2;
　}
}

function baz() {
　・・・
}

ほらね？ （戻り値でエラーを返すと）
エラー処理のほうが長くなってしまう。

まったくもってそいつのいうとおりだよ。
エラー処理のほうがこんなに長い！

しかもこれは別の問題が有る。
baz()でエラーが起きたら何度もエラーが表示されてしまう。

それを防ごうと思えば、また別の処理を入れないといけない。

そいつの言うとおり、戻り値でエラーを返すと
こんなにもエラー処理が長くなってしまう。

じゃあ、例外を使うよー？

function main() {
　try {
　　foo();
　} catch(e) {
　　alert(e.message);
　}
}

function foo() {
　bar();
}

function bar() {
　baz();
}

function baz() {
　・・・
}


はい、おしまい。

windowのerrorイベントを使えば、mainの中にも何も書かなくていいよ。

これで、bazでエラーが起きたら、ちゃんと途中で処理を中断して
一度だけメッセージを出してくれる。

もし途中で中断したくなければ、
その時だけ処理を入れれば良い。

根本的に何も理解してなかったのか…

try～catchはそういう目的に使うものではない。発生点と捕捉点を明確に区別して、コードの質を上げるのが一番の目的だ。

以前「どの行にもエラーが起こる可能性がある」ってかいてたが、上のコードではfooやbarが発生点になるエラーが何も書かれていないから、そこで起こりえるエラーを捕捉するにはそこにも「エラーが起こる可能性がある」と考えて、追加のコーディングが必要。

さらに言うとcatch節の中にも「エラーが起こる可能性がある」訳だから、そこで起こったエラーはどうするんだ？

プログラム全体をtry で囲めばあらゆるエラーに対応できるが
そんなことをするなら不正終了させたほうがいいわなw

try～catchは遅いから使うなとこのスレで教わりました
でもGoogleやその他大手IT企業も使ってました
否定派は3流プログラマなんでしょうね

本当のエラー処理で使ってるだけじゃね
遅いっていうのはエラー処理じゃないところで使うやり方のことじゃないの
知らんけど

全てに try-catch を使ったら native 関数の TypeError, SyntaxError...etc も catch するじゃないか
例外が発生して欲しい部分までエラーを発生させないコードなど、有り得ない

例外野郎は
エラー処理＝例外で補足するもの
と考えてることに致命的な欠陥がある

まともなプロダクションレベルのプログラム書いた事ないんだろうな…
エラー処理というのはエラーが発生した際に何らかの処理中だったら安全に中断させるとか
ユーザーにリトライを促す処理に移行させるとか、自動的にリトライを繰り返すとか
その際にリソースを適切に解放させる処理とかの事だ
糞面倒臭い事をたくさん書かなくちゃいけなくなる (出来のいいシステムにするにはだが)

try-catchで短くなる(ｷﾘｯっていったい何を言ってるんだといいたい

>>746
盲目的に使え(使うな)って覚えるのがダメなんじゃね？
「大手企業がそうしてるから自分もそうする」とか 。