【結構迷う】C vs. C++ 2行目【どっちで行こうか】

>>544 こんなの、とか？
int source_of_error(...);

int foo(...)
{
// ...
int e = source_of_error()
if (e != 0) return e;
// ...
}

int bar(...)
{
// ...
if (foo() == 0) return -1;
// ...
}

int baz(...)
{
// ...
if (bar()) return BAZ_ERROR_A;
// ...
}

int error_handler()
{
// ...
if (baz() != BAZ_OK)
// ...
// ...
}

>>546
それ、各ネストレベルできちんと意味のあるエラーを返していれば問題無いよね?

関数の返り値なんてデバッガでも簡単に追えるし。

>>547
こういう場合（もちろんもっとネストが深い場合含めて）のエラー通知に例外を使えば
if 文（の間違いの可能性）が減るし、デストラクタがあれば途中 return での
リソース漏れ（の心配）もなくなって、それらによって可読性が上がるとも言えるでしょ、
って話。

コードに問題が有るとか無いとかいう話じゃないし、デバッガで追うとかいう話でもない。

>>546
ふつうに読みやすいと思った

>>549 bar() がバグってるのには気付いたかい？

もちろん。バグってるかどうか局所的に判断できるし読みやすい

ネストが深い所で起きた例外って、結局は無視するか、適当なエラーメッセージを出して
異常終了するかのどちらかな気が・・・

>>552
同じ問題を示すエラーの通知方法が例外かそうじゃないかで処理方法が変わるとでもいうのかい？

>>553
それが変わらないから、『ネストが深くなった時』という問題設定自体がおかしいと思うんだよね。
そもそも何でそんなにネストするんだって話。

またまた、ご冗談を。

君に冗談を言う義理は無いよ

おやすみ〜

Cでifを使う場合と比較するなら、C++版でもcatchするべき
C++版がcatchしないなら、C版はexitを使っていい

せめてlongjmpしてくれよ。

>>546からは source_of_error() のエラー/例外は致命的で
あらゆる処理を中断して error_handler() で対処するって仕様が見て取れるけど、
そういう「コンテクストに一切依存しない source_of_error() のエラー処理」は
source_of_error() 関数内でやるのが一番読みやすいよ
もしプログラム毎にエラー処理を差し替えたいなら extern な関数でも内部で呼べば良い

次に、>>546のような深いネストがどうしても必要な場合
仮に例外で処理するなら error_handler() で catch するだろう
そうすると途中の関数は例外処理がいらないから(デストラクタで処理できるリソースだけ使ってる場合は)簡単になるけど
error_handler() を読むのが凄く難しくなる
深いネストを潜って source_of_error() まで到達する必要があるからね

例外は綺麗なgotoと呼ばれることもあるが
関数/メソッドのスコープを超える大域ジャンプなことには変わりないぜ

>>561
> error_handler() を読むのが凄く難しくなる
> 深いネストを潜って source_of_error() まで到達する必要があるからね

何のためにそんなことする必要があるの？

>>563
ソースコードのどこで（つまりどんな状況で）エラーが起こったのか知らずにエラー処理できるの？

別の言い方をすれば、いつ・どこでエラーが起こったかによらずエラー処理できる場合に
>>560のようにしてはダメな理由は？

>>564
例外使ったこと無いの？
もともと >>560 のような動作も含めて柔軟にエラー処理ができるように
考えられた言語機能が例外なんだよ。

必要な情報は例外オブジェクトに詰めて投げればいいんだ。

それに、その理由で source_of_error() まで見に行くって言うことだと、
戻り値でも同じことする必要があるんじゃないの？

> 必要な情報は例外オブジェクトに詰めて投げればいいんだ。

source_of_error() の中で必要な情報が詰められるなら、
>>560のように処理してダメな理由は？

>>566
マ板で散々議論した結果をみれば？

>>567
見てきたよ。むこうでも揉めて結論出てなかった
少なくとも>>566の疑問には答えてなかったよ

>>565
> それに、その理由で source_of_error() まで見に行くって言うことだと、
> 戻り値でも同じことする必要があるんじゃないの？

戻り値は return 探してさかのぼれば良いから読みやすいよ

デバッガでスタック遡れば良いだけとも言えるのでは？

>>566
へ？ >>560 に書いてあるのは「コンテクストに一切依存しない〜エラー処理」でしょ。
場所によって処理が違えば当然無理なんじゃないの？

それに exit() や extern 関数はライブラリに切り出しできなくなるからね。

>>569
ごく単純な >>546 で考えればそうかもしれないけど、 baz() 以下で
source_of_error() や他の失敗する可能性のある処理が１回ずつしか呼ばれて
いないとは限らない。

他にも baz() 以下のソースがあるとも限らないだろうし、 baz() 以下の
コードが未来永劫そのまま保たれるとも限らない。

例えば fopen() の失敗を処理している関数を読むときに「 fopen() のソースが
無い。困った。」なんてことにはならないでしょ。

>>572
ソースが無い場合は考えてもしょうがないと思う

例外だろうと戻り値だろうと辿って辿れないことはないと思う
ただ、戻り値の場合エラー処理してる関数だけ辿ればいいけど
例外の場合全ての関数を辿る必要あるよね（全部はちょっと言い過ぎだけど）

>>573
意味がわからないよ。

ソースが無い場合には不可能な行為を >>561 では「必要がある」と言っている。
これは明らかにおかしい。

>>564 で「ソースコードのどこで（つまりどんな状況で）エラーが起こったのか」が
エラー処理をする際に必要になると言っているようだが、 return を辿るなどしないと
得られない情報をどうやってエラー処理に使うというのか、わからない。

この状況でエラー発生位置まで辿ることを前提に話されても困る。そんな行為が
無意味に終わる理由はソースが無い場合のほかにも >>572 で挙げられている。

>>574
意味がわからないのはこっちだよ
ソースが無い場合なんて言い出したのは>>572が初でしょうに
それ以外のひとはソースがある前提で話てたと思う
だってソースの可読性の話をしてるのに、ソースが無い場合とか意味不明でしょ？

C++ PGは型が同じ例外なら、それがどこで発生しても
同じ処理でいいと思ってるのさ。
普段から「std::bad_allocだ。exitしよ」みたいなウンコプログラムを
書いてるんだろうね。
今だって、なるべくコードを読まない理屈を並べようとしてるし
ほんとコード読めないんだね。

コードの可読性の議論だったのに「コードがあるとは限らない」ワロスwww

>>575
ソースが無い場合の可読性なんてのを問題にしているわけではないよ。

例外を使った場合に可読性が下がる理由として、エラー処理しているコードを読むときには
エラー発生箇所を特定する必要があるからだ、と >>561,564 が言った。

そんな必要は無いという根拠のひとつとして挙げられているのが、ソースが無い場合。
根拠はそれ以外にもある >>572


今はこの「エラー発生箇所を特定する必要がある」の真偽を話している。その結果によって
「例外を使った場合に可読性が下がる」という主張の妥当性が変わる。

こっちでやれ。

例外を正しく使えないプログラマ多いね。 その6
http://hibari.2ch.net/test/read.cgi/prog/1298059471/