トップページ⇒tech
89コメント35KB

例外処理の効果的な使い方

■ このスレッドは過去ログ倉庫に格納されています
00011NGNG
みなさん、例外処理って使ってます？
なんか例外処理をプログラムにいれると、
ソースが汚く(＋長く)なるような気がします。
例外クラスとか作ってますか？
言語は例外処理をサポートしているものすべて対象にします。
0002デフォルトの名無しさんNGNG
当然使ってます。使わないとマトモなコードが書けないとは
言いませんが(Mozillaとか)、使いたくない理由が知りたい。
長く汚くなる実例をくださいな。

もしくは、
ttp://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.html
の「ほげ言語」のパラドックスでも読んでください。
0003デフォルトの名無しさんNGNG
いちおう使ってます。
まだへぼいプログラムしか書けないので、
ネストが深くなりすぎる時に意味不明になってますが、、。
0004デフォルトの名無しさんNGNG
>>1
Javaは例外を拾ってあげないとコンパイルもできないよ。
エラーを言語が判断してくれるのだから楽でいいじゃん。
0005デフォルトの名無しさんNGNG
>>2
Mozillaは例外処理をしてないんですか？
00062NGNG
http://www.mozilla.org/hacking/portable-cpp.html#dont_use_exceptions
を見てもらえばわかりますが、移植性を確保する目的で例外(try, catch, throw)は使っていないです。

#エラーのハンドリングを何もしていないという意味ではないですｗ
00075NGNG
>>6
そういうことだったんですね。
エラーが起きたらどうするんだろうと真剣に悩んでましたｗ
どうもありがとうございます。
0008デフォルトの名無しさんNGNG
1はどこいった?
終了？
0009デフォルトの名無しさんNGNG
>>6
つまりここでもガンはC++であるわけだ(わら
もうちょっと「まともな」言語に移ったほうがいいよ。
0010デフォルトの名無しさんNGNG
>>9
目的は移植性を確保するためだろ?
もうちょっと「まともな」言語とやらでC/C++ほど多くの実装系に移植され
てるものがあるのか?
0011デフォルトの名無しさんNGNG
>>1 の言い分は単純に「エラー処理したくない」だと思われ。
0012デフォルトの名無しさんNGNG
if文をネストしまくって事実上エラーが出ないようにするのは可能？
00132NGNG
>>11
おれもそうじゃないかと一寸思ってた。やっぱそうなのか。

>>9
C++が駄目な点はいろいろあるとは思うし、例外についてもJavaの様に
catchを強制してくれたほうが却って有難いとは思うよ。そういう縛り
を入れてくれるコンパイラなりプリプロセサなり、ないかな？
0014デフォルトの名無しさんNGNG
みな厨房
0015デフォルトの名無しさんNGNG
　 　∧＿∧
　（　´∀｀）　　　　　　　
　（　　　　) オメモナー
　 |　　|　｜
　（_＿）＿）
0016デフォルトの名無しさんNGNG
>>12
それを「エラー処理」っていうんだYO!
0017デフォルトの名無しさんNGNG
例外なしC++でエラーや例外を処理するとなると、
goto文を多用することになりますが、そんなもんですかね？
auto変数のデストラクタで処理するというのもあるけど・・・
0018デフォルトの名無しさんNGNG
try:
厨房指ネ
except 帰り打ち:
raise "オマエモナー"
0019デフォルトの名無しさんNGNG
>>13
>例外についてもJavaの様に
>catchを強制してくれたほうが却って有難いとは思うよ。そういう縛り
>を入れてくれるコンパイラなりプリプロセサなり、ないかな？

だからといっていまさらそんな縛りを入れられても困る。
0020デフォルトの名無しさんNGNG
try {
　　kill(chubo);
} catch (BOUSOU_Exception) {
　　kill(THREADS);
delete[] chubo;
}
0021デフォルトの名無しさんNGNG
↑超効果的な使い方じゃん！
0022デフォルトの名無しさんNGNG
>>17
ほとんどの場合、スマートポインタを使えば goto 不要だと思うが。
0023デフォルトの名無しさんNGNG
VBの例外処理の地獄に比べれば、天国とは言わないが
中つ国程度にはマシだと思うのだがどうか。＞C++例外
0024ナーナスNGNG
C++の例外はexception-safeなclassを作るためのsupportが素晴らしい。
0025デフォルトの名無しさんNGNG
http://www.muvc.net/kpgy/man.html
0026デフォルトの名無しさんNGNG
finallyない言語は糞言語
0027デフォルトの名無しさんNGNG
>>26
論述が苦手なのかい？
0028デフォルトの名無しさんNGNG
前提：C++だろ。Cは関係ない。そこをごっちゃにすると話が進まない。

>>10
>目的は移植性を確保するためだろ?
>もうちょっと「まともな」言語とやらでC/C++ほど多くの実装系に移植され
>てるものがあるのか?

それは明らかに本末転倒な反論だろう。
移植性といっても、CPUの違いによる制約とか
(GCとかではそういうことは有るね。boehmとか)
ならともかく、既存のC++処理系の上での話なんだろ？
じゃあC++処理系を直せとしか言いようが無いね。

ていうか「もっとましな言語」を望む環境に移植すればいいんだろ？
じゃあCかなんか(わら)で書かれたソレをその環境用にmakeすればいいんだよ。
勿論C++についてもgccで同じことをすればいいだけだし。

と書いてもなお納得できないならSqueakの話でも読むべし。
http://www.mars.dti.ne.jp/~umejava/smalltalk/squeak/index.html
勿論、Squeakが普及してるとか普及させろとかを、ここでいう積もりではなく。


>>27
26は必要最低限にして十分な内容を記述していると思われるが？
0029デフォルトの名無しさんNGNG
>>28

> それは明らかに本末転倒な反論だろう。
言語仕様と現実の処理系の完成度とを意図的に混同する事はないと思う。

> 26は必要最低限にして十分な内容を記述していると思われるが
必要十分条件って知っていて言ってる？
おそらく >>26 と >>28 はC++嫌いで通底しているから説明が不要だと思い込んでいる。
003026>27NGNG
自明です
003127>26NGNG
不毛です
0032デフォルトの名無しさんNGNG
>>26
C++ ではデストラクタの呼ばれるタイミングが明白なので、

1. デストラクタに後始末させる設計にしておく
2. スマートポインタ（もしくはローカル変数）を使う

で finally なくても困らんけどな。
0033デフォルトの名無しさんNGNG
そうだね structで関数内ローカルに　そのためだけにクラス作ってやればいいでしょ

func(a,b)
{
　struct　{
　デストラクタで後始末
　} My;
My.func(a,b);　//コンストラクタにしてもいいけど

}
0034デフォルトの名無しさんNGNG
>>32
それはfinalize()では？
0035デフォルトの名無しさんNGNG
>>34
何を言いたいのか不明なんだけど、

　Java の finalize() は呼ばれるタイミングが決まっていないので、
　finally ブロックの代わりに自動変数のデストラクタを使うことは
　できません。

で答えになってる？

C++ はデストラクタにお任せで済むのが便利なんだけど、代わりに注
意しないとリークが発生しやすいのが難ではある。

EXCEPTION HANDLING: A FALSE SENSE OF SECURITY
http://cseng.aw.com/book/related/0,3833,020163371X+11,00.html
00361NGNG
１です。いろいろ意見をありがとうございます。
ご想像の通り、C++はじめて1年ちょいの厨房です。

ソースが汚くなるというのは、関数１つ書くのに、
catchをいくつも書いたりして、それがたくさんになってくると
冗長な感じがしたので、こんなスレをたてました。
いままで、自分がみたC++のソースでまともに例外処理を使っているのを
みたことがありません。
どっかに良い例はありませんか？
0037デフォルトの名無しさんNGNG
つーか汚くて冗長で悪い例をあげてみ？
00382NGNG
おれもきぼん(再)
0039ナーナスNGNG
>>35
> EXCEPTION HANDLING: A FALSE SENSE OF SECURITY
> http://cseng.aw.com/book/related/0,3833,020163371X+11,00.html

これを初めて読んだ時は衝撃！
T pop(stack<T>); という仕様自体がexception-safeでないとは！
「実装」でなく「仕様」がexception-safeでないという事の理解は、
これ読んだ後のprogramming style/designにかなり影響を与えた。

>>36
SmartPtrが、 NullPointerExceptionをthrowする、
なんて所だけで十分にいかしていると思うが？
操作するたびに値をcheckする気するかぁ？
0040デフォルトの名無しさんNGNG
>>29
>言語仕様と現実の処理系の完成度とを意図的に混同する事はないと思う。

はぁ？むしろ、

>>もうちょっと「まともな」言語とやらでC/C++ほど多くの実装系に移植され
>>てるものがあるのか?

のほうが混同してるのだと思うが？

>>32 >>33
つまり「例外出ようが出るまいが必ず通るコード」を
「局所クラス(のインスタンスのデストラクタ)」でエミュレートしようというわけね？

…「綺麗」ではないね。

念のため言っておくけど、
「必ず通るコード」が常に1つのObjectとして(デザイン的に)表現されるのが自然か？
というと、そんなことは無いわけだから。

>>34
全然違うぞ(^^;
finalizeとfinally(とついでにfinal(わら))とは別モノだ。
0041デフォルトの名無しさんNGNG
ちうか例外ってOOPとは、まったく異質な機構なんで
ソースに加えると違和感が残る。
よって俺は使ってません。
0042デフォルトの名無しさんNGNG
>>40
例外の話をするのでなければスレ違い。オブジェクト指向言語の実装
の美しさについて語りたいなら、別スレッドに逝ってくれ。
0043デフォルトの名無しさんNGNG
Delphiの
try
　try
　　...
　except
　　on E: Exception
　　　;
　end
finally
　...
end
ってやたらとインデント深くなるのは何とかならんのか
ついでにexceptに対になる例外が出なかったときのみ
実行されるブロックが欲しいな。まあなくてもあんまり困んないけど。
0044デフォルトの名無しさんNGNG
>>41
例外機構ってどっちかというとアスペクト指向なのかもね。
0045デフォルトの名無しさんNGNG
ちうかC++のintってOOPとは、まったく異質な機構なんで
ソースに加えると違和感が残る。
よって俺は使ってません。
0046デフォルトの名無しさんNGNG
>>41
たしかに別ものではあるが、互いに「相性」は良いと思うのだが。
XPのプラクティスみたいに、互いが互いを必要とするみたいな。

>>43
>exceptに対になる例外が出なかったときのみ

それは時折思う。というかFinallyって
例外出た時(except相当)と出なかった時のどっちも同じ実行パスになる、
というだけだから、アトミックに考えるとexceptとnon_exceptさえ有ればいい
のかも知れず。

こないだ作った自作言語でそれっぽい実装にしてみた。

try foo bar zot
#foo/bar/zotは手続きへのポインタ。
#この言語では無名手続きを任意の場所で書ける。

っていう感じで、fooを実行して例外だったらbarを、例外じゃなかったらzotを、
実行するっていう文法(?)にした。

で、手続きポインタなので、ポインタを2回参照しちまえばいいのね。つまり、

ex={finally処理の無名手続き}
try {hogehoge} ex ex

これでfinally相当の出来あがり。hogehogeが例外起こしても起こさなくてもexに飛ぶ。
0047デフォルトの名無しさんNGNG
つーか、コンストラクタがエラー値を返せないから例外使うんじゃないの。
別口で init() 呼ぶとかいうなよ。
004843NGNG
>>46
>アトミックに考えるとexceptとnon_exceptさえ有ればいい
>のかも知れず。
exceptとnon_exceptの共通処理をfinallyに記述しないと冗長になるので
try

non_except

except

finally

end
って構文が良いと思う。これならインデントも最小に抑えられるし。
いまのところ実装してるのRubyくらいかな？

Delphiはtry廃止してbeginにしちゃうとなお良いかも。
if xxx then
try

finally

end
なんてのが良くあるし、メソッドの一番外側のブロックでも例外処理できるので。
0049デフォルトの名無しさんNGNG
>>41
ということは STL は使わず operator new も再定義してるんでしょう
か？
0050ナーナスNGNG
>>47 追加
objectの中にerror flagとかいうなよ。
0051>47NGNG
コンストラクタ以外に例外生成するメソッドなんてたくさんあるだろ
0052デフォルトの名無しさんNGNG
>>40
綺麗じゃないかどうかは主観だと思うな
　他に方法あるとしたら、 catchして投げ返すしかないけど
　これだと同じ手続きを２個所に書かなけりゃいけないんじゃない？

　だとしたらそれよりは綺麗なコードだという視点もあるでしょ？

後は、では finally相当の為のコードである事をどう他人が読んでも
判るかという問題じゃないの？

まあ、関数やメソッド内で　classじゃなくてstructでデストラクタ宣言
してたら９割はfinally代わり　だと予想しながら読んじゃうけどね
0053お願い名無しさんNGNG
>当然使ってます。使わないとマトモなコードが書けないとは
>言いませんが(Mozillaとか)、使いたくない理由が知りたい。

例外オブジェクトがメンバ変数を持っている場合、
正しく初期化できない場合があった。
exceptionからerrnoを持つクラスを導出したら
xexception::xeception(): errnumber(errno) {}
それを初期化できなかった。コアダンプすることもあった。
使っているコンパイラのバグだと思う。
0054ナーナスNGNG
なんだ、使いたくないコンパイラがあるという話か。
0055デフォルトの名無しさんNGNG
>>53
テンプレートや例外なんかは後から加わった機能なんで、以前は、実
装が甘い処理系があったのは確か。ただ、さすがに最近は例外まわり
でバグが残っている処理系は少ないと思う。

むしろ、今ごろそんなバグが残ってる処理系は捨てる準備を始めたほ
うが。過去の資産が……といって捨てずに後生大事に使っていたら、
コンパイラベンダ自体が撤退してサポート打ち切りとか、ありがちな
話。

そういえば、ゲームや組み込みなんかでは例外って使われてる？　主
記憶 64KB とかの世界だと C++ 自体がお呼びじゃないと思うけど、
最近のゲーム機って主記憶 32MB とか積んでるから、開発手法も以前
とは変わってると思うんだけど。
0056デフォルトの名無しさんNGNG
例外というか LONGJMP なら使うな
0057デフォルトの名無しさんNGNG
>>53
errno使うのは止めたほうがいいんじゃない？
マルチスレッド対策でマクロになってる処理系もあるし
0058デフォルトの名無しさんNGNG
Javaはあまり詳しくないが、Javaのfinallyの話を聞いて
どうしてもC++でfinallyがほしくなって、こんなことをした覚えがある。

(ちょっと記憶あいまい、まちがっているかも。でも趣旨は伝わってくれると思われ)

class __finally_exception
{
};
class __finally_raiser
{
public:
　　~__finally_raiser()
　　{throw __finally_exception;}
};
#define try_with_finally \
　try { \
　　__finally_raiser __finally_raiser_object;

#define end_try_with_finally \
　}

#define finally \
　catch(__finally_exception&)


で、

try_with_finally
　　.
　　.
end_try_with_finally
catch(hogehoge_exception&)
{
　　.
　　.
}
finally
{
　　.
　　.
}

tryブロックの中にデストラクタで例外を投げるautoオブジェクト
作れば、tryブロックを抜けると例外が投げられるからそれをcatchする
ということです。

でも、アホらしくなって使うのやめた。
0059＃6411NGNG
>>55 主記憶 64KB とかの世界だと C++ 自体がお呼びじゃないと思うけど

主記憶64KBでコンパイラ処理系が使えるっていったら、
目が怒ライブかなあ? あの頃はC++自体が
マイナーだったし、そもそも漏れは瀬賀系にはあまり携わって
なかったような。Cだったら、基本的にはROM化の手法と
あまり変わらないんで、使いではあったとおもう。
主記憶2MBのプレ捨てでは、C++使ってた。
ただし、既存ライブラリは一切使わず、「便利なC」としての
使い方が多かったけど。(継承とかは使ってたよ)

漏れがC++に手をつけ始めた頃は、
gccに例外処理がまだ実装されてなかった。
鬱だ…
0060デフォルトの名無しさんNGNG
>>58
>でも、アホらしくなって使うのやめた。
やめたのは正解かもしれないが、C++のトリッキーな技を垣間見たようだった。
0061デフォルトの名無しさんNGNG
lispならfinally構文作って終りなのにね。
unwind-protectあるから必要無いけど。
0062デフォルトの名無しさんNGNG
> xxならいいのにね。
xx厨房の典型的な書き込み
0063デフォルトの名無しさんNGNG
ﾋｶﾞﾑﾅ>62
0064忠房NGNG
やっぱりlispがオススメれすか？
0065デフォルトの名無しさんNGNG
win32の構造化例外処理は？
0066デフォルトの名無しさんNGNG
ソフトウェア設計の書籍だと、オブジェクト指向でのクラス階層の
分析・設計は良く見かけるが、例外クラスの設計は見たことがない。
何かお勧めの文献（もしくは C++ ならソースコードでも良いけど）
あります？
0067デフォルトの名無しさんNGNG
　　　　　　　　　？ ？
　　　　　ﾌﾟｲｯ／.⌒｀.　　 ┌────────
　　　　　　ヾ( ∈三∋)　＜　シラネーヨ
　 ﾅﾆｯ!　　/　 ／￣　　　 ﾉ)―───────
　∧ Λ　 （　 (￣￣⌒ヽノﾉ
　( ﾟДﾟ)￣ ＼　　　　　　　Y
　　U U￣￣/ノ ）ノ￣)ノ＼)
0068デフォルトの名無しさんNGNG
>>66
>例外クラスの設計は見たことがない。

(よくみかけるような設計ほど大げさなものは)要らないと思う。

なぜなら、例外Objectって、これといって他のObjectと
関連とかなんとかを持ってないでしょ。
単にそのObjectが存在すればいいんです。例外Objectは。

あれは、全ての味噌はクラス継承ツリーです。
(設計者が)例外事象をどう「分類」したいと思ったか？を
そのままクラス階層にあらわせばいいんです。

例外Objectが有ったら、それに我々が期待する機能は、
「そのクラスがナニなのかを知る」
「ついでにエラーメッセージを持っていたらそれも読む」
くらいなもんです。

#だから逆にいえば、Reflectionの弱い言語だと、情けないことになるんだけど。
0069デフォルトの名無しさんNGNG
例外を投げる場面、投げない場面の使い分けがよくわかりません。
MFCでも、例外なげてるのはFILE関連くらいで、ほとんどは戻り値でエラーを
知らせてますよね？
ていうかMFCを手本にするのが間違ってますか？
0070ナーナスNGNG
>>66
例外のクラス階層も悩ましいのは悩ましいけど、
全体の仕様がチャンとして入れば、そんな難しくない。>>68のいう通り。

それより難しいのは、program全体をexception nuetralに作る事。
exceptionが起きた時に異常な状態にならないようprogrammingするのは、
そのconceptを知らない人には難しい。特に他人の作ったlibraryも使っている時は。

とりあえず、上のfalse senseは必読ですよ。
これ読まないで何度も使う予定のexeptionを使ったlibrary作っちゃ駄目。
”Exceptional C++"(C++ puzzle bookみたいなもの)にも載ってるよ。これは翻訳があるし。

http://cpptips.hyperformix.com/Exceptions.html
Guru of the Week, http://www.gotw.ca/gotw/008.htm
0071ナーナスNGNG
>>69
> ていうかMFCを手本にするのが間違ってますか？

間違ってます。
Exceptionがなかった頃の設計ポリシーを引きずってます。

C++で閉じていいなら、どんどん使いましょう。

Windowsはsignal等、C++的でないものも存在して、
これはlanguage nuetralな機構だから、ないわけにもいかないよね。
0072デフォルトの名無しさんNGNG
signalはどっちかっていうとunixでは？>71
0073例外処理勉強中NGNG
C++でfinally代わり
try
{
Func();
Finally();
}
catch(char *str)
{
Error(str); //自分で作った例外の処理
Finally();
}
catch(...)
{
Finally();
throw; //その他なので外に投げ
}
どこ通ってもFinally()が呼ばれるということで…
こういうこととも違う？違うと思うので寝る。
0074デフォルトの名無しさんNGNG
オートポインタとかauto変数にすんのじゃだめなの?>73
007573NGNG
>>74
勘違い。そっちのほうがな。
73は無かったことに…(;´Д｀)
0076デフォルトの名無しさんNGNG
例外導入はオブジェクト指向言語では必然的
0077デフォルトの名無しさんNGNG
手続き型言語にも欲しいよ
オブジェクト指向に限定することないっしょ
0078デフォルトの名無しさんNGNG
Eiffelの表明を使った例外処理が好き。
0079デフォルトの名無しさんNGNG
エラー処理にgoto使うのは厳禁なんですか？
0080デフォルトの名無しさんNGNG
ちょっと話は違うかもしれんけど、
DelphiのAbortっていいよね

キー入力をキャンセルしたけりゃ OnKeyPressでAbort投げるだけでいいし
とっても便利お手軽さん
0081デフォルトの名無しさんNGNG
>>79
メソッド(関数)の呼び出し階層の深いところでエラーが起きたら
そこから一番上にはgotoできない。ので例外なりlongjmp云々な
わけで。
0082デフォルトの名無しさんNGNG
>>77
欲しいってのは確かなんだけど、一方で、
例外の種類分けのための例外Class(の階層)を使えないのが悲しい。

ただ、逃げる手は有る(ので誰かそういう言語作ってくれ)。
階層を表現するために丁度いいデータ構造があればいいんだ。

一番卑近なものとして、ファイルのフルパスを連想すれば判るだろうけど、
「文字列」ってのが有ると思う。
つまり "Exception/IOException/FileReadException"
(冗長なので実用するときはもうちょっと縮めるのがお勧め)
みたいな文字列を使って例外分類をやる、という言語があればいい。

分類を吟味するときはもちろん部分文字列照合でヤル。
頭からマッチング調べればいい。
だから一番一般的な例外Object(?)は、 "" (空文字列)だと思われ(藁)
0083ナーナスNGNG
>>72
ｽﾏｿ、 SEHと書いたつもりでした。

SEH: Structured Exception Handling
0084ナーナスNGNG
>>74
Destructorで済むものはそれでいいと思うけど、
利用方法依存の後始末をやりたい時にfinallyあれば嬉しい事もあるな。
CLOSの:after-daemonがあれば、使い捨てclassをon the spotに書けるのに。

VC++には、>>73みたいなマクロが__try/__catch/__finallyってなかったっけ？
0085名無しさんNGNG
>>84
だから、
__try/__catchがSEH(構造化例外).
alarmに該当するのがRaiseException
signalハンドラに該当するのが__catchブロック
通常はSEH投げるとデストラクタをバイパスするんで×。
未定義の構造化例外を使ってC++のtry/catchが実装されててる。
これはthrowを__catchで捕らえるプログラム書いてテストすると分かる。
008685NGNG
__catch->__except()
鬱死。
0087デフォルトの名無しさんNGNG
>>70
Exceptional C++ 買おうかと思うんだけど、邦訳の質はマトモですか？　あまり
良くないなら原書を注文しようかと思ってます。
0088デフォルトの名無しさんNGNG
age
0089ナーナスNGNG
>>87
> 邦訳の質はマトモですか？

GoTWと原書を読んだので、知らない。
■ このスレッドは過去ログ倉庫に格納されています