トップページ⇒tech
221コメント62KB

例外処理exception, runtime_errorの使い方

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
例外処理の使い方、問題点を検討。

先ず１問目。
std::runtime_errorでエラー文字列を上に渡すことが出来ます。
しかし、多国語対応だとクラスの中に膨大な文字を持つようになります。
かといって、エラー文字列取得クラスなんて用意する、汎用的なクラスになりません。
やっぱ、runtime_errorは捨てて、素直にexceptionを派生するべき？
0002デフォルトの名無しさんNGNG
get_2_exception
0003デフォルトの名無しさんNGNG
先生、わかりません
0004デフォルトの名無しさんNGNG
織田信長について語ってるの？
0005デフォルトの名無しさんNGNG
そうそう、織田信長って良く構造化例外使ってたよね。
0006デフォルトの名無しさんNGNG
既存スレへどうぞ。

C++相談室 part18
http://pc2.2ch.net/test/read.cgi/tech/1050177746/
0007デフォルトの名無しさんNGNG
文法じゃなくてアプリ構造についても考えたいＹＯ！
0008デフォルトの名無しさんNGNG
特にエラー例外ってのにこだわらなければ使い道はいろいろあるかと。
たとえば、シーンチェンジに使ってたりします。
0009デフォルトの名無しさんNGNG
>>8
そういう使い方はやめろ。
0010デフォルトの名無しさんNGNG
>>9
なんで？結構便利だなって思ってたんだけど。
私はプログラムの経験が少ないんで問題に気づいてないのかもしれないですね。
できればシーン変更の標準的な方法を教えてほしい。
0011デフォルトの名無しさんNGNG
>シーンチェンジ
なんだけ？RPG？
0012デフォルトの名無しさんNGNG
多重whileから一気に抜ける時に使います
gotoよりはいいでしょ。
0013デフォルトの名無しさんNGNG
例外は遅くは無いとは聞いたことあるけど。
0014動画直リンNGNG
http://homepage.mac.com/hitomi18/
0015デフォルトの名無しさんNGNG
多重whileというかメソッドからメソッドを呼んでとか多重入れ子になってる状態で
一気に親メソッドに戻りたいときはいいね。
0016デフォルトの名無しさんNGNG
>>12
おいおい
0017NullPointerExceptionはぬるぽNGNG
別会社のとあるコードみたときに、
本チャンコードが５行程度で
例外処理が３０行以上のコード見たことがある｡

「なんでや？」と聞くと
「あ、それ０で助産したときの処理です」とこきやがった｡
確かにそのとおりだったが

･･･
0018デフォルトの名無しさんNGNG
>>17
構造化例外にすると１行になるコードかい？
0019デフォルトの名無しさんNGNG
>17
例外処理のコードが少なすぎるって言いたいのかな？
0020デフォルトの名無しさんNGNG
エラーメッセージの扱いどうしよう。

多言語対応したくて、組み込みからWindowsをカバーしたい場合。
0021デフォルトの名無しさんNGNG
gettextを使う
0022デフォルトの名無しさんNGNG
スロウラブルで幸せを掴もう。
0023デフォルトの名無しさんNGNG
>>17
例外処理で３０行？いいんでないの？
サーブレットの話しだけど例外発生したらエラー画面に飛ばすとかの処理
書いたらそれくらいならない？
画面に飛ばす処理を共通化するならn行で済むけど。
0024デフォルトの名無しさんNGNG
漏れはもっぱら RuntimeException の例外しか作らん
0025デフォルトの名無しさんNGNG
今までBCBだったので、
throw Exception("")
したら、メッセージボックス出力されてました。
が、MFCのプログラムだと異常終了します。
MFCな人達はどうしてますか？
002625NGNG
ちなみに、MFCではthrow runtime_errorしてますが、
やっぱ、トラップを自分で書くしか無いかな。
BCBのプロジェクトファイルみたいなのはどこにあるんだろう。
0027デフォルトの名無しさんNGNG
自作例外クラスはどう設計すればいいでしょう？

Exceptionクラスを継承してコンストラクタでsuper(String message)を呼び出しているだけで
終わってしまっていますが・・・
0028デフォルトの名無しさんNGNG
http://www.boost.org/more/error_handling.html
0029デフォルトの名無しさんNGNG
ｓｔｄ:::bad_alloc例外投げる時にさらにメモリ不足になったりしないかと夜も眠れません
0030デフォルトの名無しさんNGNG
>>25-26
CWinApp派生クラスのInitInstance, ExitInstanceと、
メインウィンドウのWindowProcでtry-catchしてSEH以外は全部捕まえてる。
特別なエラー処理をしたいハンドラはそのハンドラで独自にtry-catch。

>29
MFCのAfxThrowMemoryExceptionは
グローバル変数へのポインタを飛ばしてるだけだから
メモリを確保しない…んじゃなかったかな。

std::exception派生クラスでそういう仕組みは作れる？
0031デフォルトの名無しさんNGNG
> そういう仕組み
ってなあに？
0032デフォルトの名無しさんNGNG
bad_allocとruntime_errorと、多重継承出来る？
0033デフォルトの名無しさんNGNG
「Javaの鉄則」本に、例外が現れたらそれらを上書きで隠さずにVectorクラスに溜め込む
技があったな。

Vectorに溜め込む専用の例外クラスまで用意していたが、
汎用性がどれだけ高くなるか疑問。
0034デフォルトの名無しさんNGNG
>例外が現れたらそれらを上書きで隠さずにVectorクラスに溜め込む

役に立つの？
役に立つなら、C++版を作成しようかな、と。
0035デフォルトの名無しさんNGNG
>>30
WindowProcでキャッチするのは確かに気持ちいいんだが、
例外をOSのDLLのスタックを通過させないように注意しろよ。動作が不定になるぞ。
サブクラス化した場合とかは特に、そっちのWindowProcでもちゃんと全catchするように。
003630NGNG
>>35
何か大変だね。やめとこう。
BCBなら普通に出来ることなのにね。
TApplication::OnExceptionていうイベントハンドラさえあるのに。
0037bloomNGNG
http://homepage.mac.com/ayaya16/
0038デフォルトの名無しさんNGNG
>>36
別に大変ではないからやりなさい。
003930NGNG
>>31
えーと、MFCの場合は
CSomeException g_GlobalException ; //CException派生、グローバル変数

throw &g_GlobalException ;
とポインタを投げるので例外処理時にメモリを新たに確保しない。
（スタックは使うのかな。分かんない）

STLだと
MyException g_E ; //std::exception派生、グローバル変数

throw g_E ;
と投げて受け側が
catch(std::exception& e)
と受けてもどこかで例外オブジェクトがコピーされちゃうんじゃない、か、
と思っちゃったんだけど…

コピーされないか。されませんね。すみませんでした…
004030NGNG
>>35
げ！？
OSのDLLのスタックを通過って、
DispatchMessage API の外側でtry-catchしちゃまずいとかそういうこと？
全然意識してなかったよ…。

＃ところでこのスレって環境依存の話ばっかりしちゃまずい？
004130NGNG
>>36
って、キミは誰だ？オレか？

MFCにもCWinApp::ProcessWndProcException
というのがあるけどCException派生の例外しか処理してくれないのでね。
0042デフォルトの名無しさんNGNG
ぼく知ってるよ。throwで投げたものはぜったいコピーされるんだ。
0043デフォルトの名無しさんNGNG
dll内の関数が投げた例外って、dll内でcatchしないとアプリ落ちちゃいません？
0044デフォルトの名無しさんNGNG
OSがDLLを提供するのは良いが、OSのDLLは関数ベースで例外出さなくて綺麗だよね。
VC++なんかの、DLLの例外をアプリがcatchすること自体キショイような気がする。
0045デフォルトの名無しさんNGNG
>>28
うわっ、例外のコピーコンストラクタが例外を投げたら、terminate()
呼ばれるんだ。コンストラクタが例外投げたときと同じように、
新しい例外の方が有効になるんだとばっかり思ってた。
でも、よく考えると、例外オブジェクトの領域は普通は一箇所だから、
新しく例外を投げようとするとオブジェクトを上書きしてしまうのか。
0046動画直リンNGNG
http://homepage.mac.com/hitomi18/
0047デフォルトの名無しさんNGNG
VC++/MFCで、
std::runtime_errorを派生したいんですが、
なんかコンパイルエラーの嵐です。サンプルきぼんぬ。
0048動画直リンNGNG
http://homepage.mac.com/hitomi18/
0049デフォルトの名無しさんNGNG
↑ぬるぽ刑
0050デフォルトの名無しさんNGNG
以前読んだ本に
「コンストラクタで例外を投げるのはオススメできない」
って書いてあったんですけどコレはなんででしょう？
特に理由も書いてなかったし

今までバリバリ例外投げてたんですけど、これってマズイ？
0051デフォルトの名無しさんNGNG
ﾏｽﾞｸﾅｰｲ
0052デフォルトの名無しさんNGNG
>50
MSDNの"Deep C++"にあれこれ書いてある。
ttp://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/jpdndeepc/htm/deep01202000.asp

どうせアプリケーションを終了させなきゃならないような例外だったら投げても
いいかと思うけど。
0053デフォルトの名無しさんNGNG
>>52
第１４部だけ張るとは、恐ろしい罠だな。
気をつけろよ。>>50
0054デフォルトの名無しさんNGNG
つうか俺はほとんどコンストラクタ位でしか例外を投げてない
005552NGNG
>53
おお、言われてみれば。13部〜16部くらいがこのあたりの話。
でも全編読むべきなのだろうな。
…なんか難しくてよく分からんのだが。
0056デフォルトの名無しさんNGNG
なんか和訳がわかりにくいな
0057デフォルトの名無しさんNGNG
>>55
問題は、14部から後に筆者の意見が逆転してることだな。
0058デフォルトの名無しさんNGNG
例外というのかわかんないんだけど、
Windowsアプリでint系の割りこみハンドラって作れるの？
0059デフォルトの名無しさんNGNG
 作れる
0060デフォルトの名無しさんNGNG
例えば、
奇数アドレスを参照しようとしたら例外(int)飛ばす事にしたいんだけど、
できるんでしょうか。
0061デフォルトの名無しさんNGNG
そもそも奇数参照で例外出す機能がx86にあったか？
ペナルティで実行クロック余計にかかるだけでは・・・最近の知らんが。
ﾓﾄﾛﾗとかあっちならあったな。
0062デフォルトの名無しさんNGNG
無理やりunsigned longあたりにキャストして0x01とAND
0063デフォルトの名無しさんNGNG
MSVCP60.DLLから飛んでくるstd::ios::failureがstd::exceptionで捕まえられないんですが、
心当たりの在る方はいらっしゃいませんか。
RTTI有効にしてるのがイカンのだろうか・・・
0064デフォルトの名無しさんNGNG
例外処理って使いどころがわからん・・・
0065デフォルトの名無しさんNGNG
例外処理しなければアプリが不正に動作してデータ壊したり、異常終了するだけですが...
0066デフォルトの名無しさんNGNG
>>64の言う例外処理はC++のtry&catchのようなものを指すのでは。

if使って書くよりよほど見やすいと思うけど・・・
0067デフォルトの名無しさんNGNG
たとえば、ファイルの入力をストリームと見た場合、
終端(EOF)は例外。
0068デフォルトの名無しさんNGNG
>>59
windowsの３２ビットモードのアプリで
intのハンドラを書きたい場合どうすればいいんでしょうか？
というか、ＯＳが提供してる割りこみの種類がわからないんですが・・。
MSDNとかに載ってますか？
0069デフォルトの名無しさんNGNG
例外をキャッチしないとterminate()が呼ばれるわけだけど
set_terminate()で設定した関数の中で例外をスローするとどうなるんだろう？
しないほうがいいのは前提として
0070デフォルトの名無しさんNGNG
鼻から悪魔
0071デフォルトの名無しさんNGNG
mainがC言語だと、throwするのも不安だね。
0072山崎渉NGNG
　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉
0073デフォルトの名無しさんNGNG
電源が抜かれたときにもファイルが妥当にクローズされてるような例外ってどう書けばよいですか？
0074デフォルトの名無しさんNGNG
マシンにUPSつけるしかないだろ。
で、OS依存の例外をキャッチするとか

あるいは電圧監視プログラムをバックグラウンドで走らせて、
電圧落ちたら運がよければ例外スロー

0075デフォルトの名無しさんNGNG
みんな例外に興味ないすか・・・
(´･ω･`)
0076_NGNG
http://homepage.mac.com/hiroyuki44/
0077デフォルトの名無しさんNGNG
使える環境では日常的に使いすぎて、書き込むようなネタはない。
使えない環境は関係ないし。
0078デフォルトの名無しさんNGNG
例外オブジェクトの中にエラーメッセージを構築するための情報を
ぶちこむと思うんだけど、どんな感じで入れる？

例えばWindowsのAPIがエラーを返してきた場合だと
エラーが発生したAPIと、APIに渡した引数、APIが出すエラーコード、
APIを呼んだ箇所によっては特別な対処用メッセージ、などなど。

これらをさっくりぶちこんだ例外オブジェクトを構築するコードを
1,2行で書けるような仕組みを作れればいいんだけど…
0079デフォルトの名無しさんNGNG
if( えら？ )
{
　std::ostringstream ss;
　// ぶちこむ
　throw えら( ss.str() );
}
0080デフォルトの名無しさんNGNG
exception 継承して what() でエラーを得てはダメなんでしょうか？？
0081デフォルトの名無しさんNGNG
俺はふつうにそうやってるけど。なんで「ダメ」だと思うのさ？

あと「コード１，２行で」っていうけど、マクロ使えば何行だって大差ないし。
008280NGNG
>>81
変なことを聞いてすいませんでした。

ほとんどのサイトで自前のExceptionとか定義してそこから派生させていたので
<exception>は普通あまり使われないのかと思ったんです。
008378NGNG
>79-82
それはそれで正しいと思うんだけど、
「コンピュータに詳しくないエンドユーザーが、エラー発生時に
どういう対応すればよいのか分かるように。」
「ユーザーを小難しいメッセージで混乱させないように」
というようなことを言い出されるとこれがなかなかむつかしい。

try {
foo(argument);
}catch (SomeException& e) {
//この例外の場合は原因メッセージが必要
throw HogeException(HogeMessage + "（原因は" + e.what() + "）");
}catch (OtherException& e) {
//eの種類によってはe.what()はユーザーに見せたくない
//argumentは見せる必要がある。
throw FugaException(FugaMessage + argument);
}

なんてやってるとどんどんふくれあがってゆく。
0084山崎 渉NGNG

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣
0085山崎 渉NGNG
（＾＾）
0086山崎 渉NGNG
　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン
0087デフォルトの名無しさんNGNG
BCBでは、exceptionでなくて、Exception使うべき？
0088デフォルトの名無しさんNGNG
>>87
Del厨は(#・∀・)ｶｴﾚ!!
0089デフォルトの名無しさんNGNG
HEWのC++でも、ちゃんと、catch動きますか？

やっぱ、__finallyは無いですよね？
0090デフォルトの名無しさんNGNG
HEWってstd::runtime_error無いの？
0091デフォルトの名無しさんNGNG
質問です。
数段の関数呼び出しをした中の処理でプログレスバーが出て、
ユーザーがキャンセルできる場合、
キャンセルを例外としてthrowするのは問題ないでしょうか？

現状、エラーは例外をthrowするけども、
キャンセルだけは戻り値（二値）になっているコードがあって、
処理の結果を返したいときに戻り値が使えなくてちょっと不便に思っています。
0092デフォルトの名無しさんNGNG
>>91
問題ない。
エラークラスを派生して、エラーコードメンバを足せば？
0093デフォルトの名無しさんNGNG
C++でまともにバックトラック処理書く手段が例外飛ばししかないのがな。。
意味的に例外じゃないのに。
安全なlongjmpとか用意すべきだったと思わない？
0094デフォルトの名無しさんNGNG
>>93
バックトラックって，用意したスタックをロールバックするだけじゃない?
0095デフォルトの名無しさんNGNG
>>93
> 安全なlongjmpとか用意すべきだったと思わない？

それがexception。
0096デフォルトの名無しさんNGNG
例外クラスをどういうときに作るべきかで迷う。

0097デフォルトの名無しさんNGNG
>>96
そりゃ、catchを分岐させる必要があるときでわ？
0098デフォルトの名無しさんNGNG
処理系のエラーオブジェクトしかthrow出来ないと思ってたが、
char *の文字列なんてものthrow出来るんだね。
組み込みだと便利かな？
0099デフォルトの名無しさんNGNG
いちいち関数の戻り値見ながらエラーだったら呼び元にエラーを返してと
とぼとぼやるよりは例外投げたほうがストレートでいいじゃん。
デストラクタを適切に実装していれば途中のオートオブジェクトも
自動的に消えて元にもどるわけだし。

システムコールのエラーもエラーリターンなんで
面倒なことはやめて全部例外投げる。

ってのは乱暴?
0100デフォルトの名無しさんNGNG
> システムコールのエラーもエラーリターンなんで
> 面倒なことはやめて全部例外投げる。

意味わからん。
0101デフォルトの名無しさんNGNG
>>100
int read_e(int fd, char *buf, size_t nbyte)
{
　int r;
　if(-1 == (r = read(fd, buf, nbyte)))
　　throw errno;
　return r;
}
0102デフォルトの名無しさんNGNG
>>101
throwでint投げるんだね。

intとchar *とどっちが良いのか迷ってまつ。
0103デフォルトの名無しさんNGNG
char *を投げる場合、スタックに取ったchar変数だとマズイんだろうね？

"error:〜"みたいにべた書きしとけば大丈夫？
0104デフォルトの名無しさんNGNG
>>103
staticで定義しとくとか
0105100NGNG
>>101
ん？
「エラーリターンなんて面倒なことはやめて全部例外投げる」
ってことか。それなら納得。

でも、 throw errno; はあんまりだな。
systemcall_errorとか、専用の型を作って、
what()でstrerror()が出るようにするのがよさそう。
0106デフォルトの名無しさんNGNG
エラーオブジェクトってのは、通常のクラスで良いのかな？

エラーオブジェクトが関数のスコープ抜けたら消滅しても困るし、
上位でcatchされてスコープ抜けたらオブジェクトが消滅した方が良いし。。。
0107デフォルトの名無しさんNGNG
>>106
C++/Javaなら、例外の基底クラスがあるので、
そいつから継承したものにするのがマナー。

C++でthrowに渡したオブジェクトは、
必ずコピーされたものがcatchに渡されるので、
特別な寿命管理は必要ない。
0108デフォルトの名無しさんNGNG
>>107
なんと、HEWのC++には例外基底クラスも無ければ、STLも無い。

ついでに、char *に使えるのはどうなってるかも教えて。
ローカル変数のcharのポインタはやっぱダメ？
0109デフォルトの名無しさんNGNG
>>108
別にポインタ自体の入れ物はローカル変数でもいいが
その参照する文字列がプログラムスタック上に確保されるような場合は×
静的に領域を確保しておくか、例外を投げるときにnew、catchステートメントでdelete
JavaだとガベージコレクトされるからnewでもいいんだがC++だと明示的に
deleteしてやんないとね
0110デフォルトの名無しさんNGNG
俺もＨＥＷ使ってるよ。
タスクＡでtryの中に入ってるとき、タスクＢに制御が移り、
その最中でthrowしたらタスクＡのcatchでとらえられたのはびっくりした。
例外ってそんなもんなの？ＨＥＷだけ？

あと、GCCもそうかもしれんが、ファイルをまたがって例外が飛ぶ時、
RTTIをチェックしないといけないのが引っかかった。


ま、ＳＴＬもそうだけど、ＨＥＷはいままで触ったなかでかなり悲惨な部類の環境だなぁ。
0111デフォルトの名無しさんNGNG
>>110
その動作は至って普通です。

throwって要は「例外オブジェクト」をスタックやレジスタにセットして大域ジャンプ
してるだけなわけで。
アセンブラの言語レベルの理解は別にいらないけどスタックやプログラムカウンタ
まわりの概念が解ってればそんなに難しくないと思う
0112デフォルトの名無しさんNGNG
>>110
>その最中でthrowしたらタスクＡのcatchでとらえられたのはびっくりした。

こうなると困るんだっけ？
普通な気がするが。
0113デフォルトの名無しさんNGNG
>>110
>ま、ＳＴＬもそうだけど、ＨＥＷはいままで触ったなかでかなり悲惨な部類の環境だなぁ。

SH使ってまつ。HEWよりマシで、価格がそう変わらない環境教えて下さい。
0114デフォルトの名無しさんNGNG
>>111,>>112
それ本気で言ってる？そんなんなら、例外構文なんて使えねーだろ。

>>113
逆に、ＨＥＷより劣る環境をどんだけ知ってるんだい？
0115デフォルトの名無しさんNGNG
>>110
その実行環境で言うところの、タスクって一体何?
それがほとんどモジュールと同じで、
システム全体でシングルタスクスケジュールで動いているのなら、
そういうこともあるだろうけども…
0116デフォルトの名無しさんNGNG
>>115
ITRONの言うタスクはWinでいうスレッドのことでつ。

システム全体というか、機器全体で１つのEXEみたいなものですが、何か？
0117デフォルトの名無しさんNGNG
実は、例外機構がどのように実装されているのか知らんのだが、（レジスタの値を退避させるらしいけど･･･）
それを保存するとこはどこなんでしょ？
ＨＥＷは例外機構を使う場合、例外を使うと明示的にコンパイラに指示する必要がありまして、
もし指示しなかった場合は__curr_stack_entry（だったか？）がリンクエラーになります。
つまり、ここに全ての場所の、例外の継続情報が保存されるんじゃないかと。
だからタスク間で勝手に例外がとんじゃったのかな？と考えてみた。
0118デフォルトの名無しさんNGNG
>>117
ローカル変数のdestructorを実行しないといけないので、
ローカル変数のあるブロックごと、tryブロックごとに、
スタック上に印をつけておいて、それを実行環境が巻き戻しながら、
必要な処置を行っていきます。つまりスタックの操作を行います。

__curr_stack_entryってのは、
その現在のブロックのスタックを返す関数でしょう。(たぶんアセンブラ記述の)
0119デフォルトの名無しさんNGNG
ということは、try-catchをタスク毎に動作というかタスクに閉じたくても、
HEWはITRONのタスクを知ってるわけじゃないから、
それは不可能ってこと？？？？？

OSとコンパイラとセットじゃないと実装出来ないということかなぁ。
ITRONじゃC++実装不可能ってことか。
T-KernelはOSのソースを統合してるから対応可能なんかな、、、
0120デフォルトの名無しさんNGNG
普通タスクごとにスタックは別だから、
なんか特別なことやってなければ、
例外処理でタスク間を移動することはない。

>>110はなんか勘違いしたが、
programのbugによる異常動作だと思う。
0121デフォルトの名無しさんNGNG
thanx!>>120

実際HEWでthrow使っている人は居ますか？
「throw -1」なのか「throw "error: details〜"」みたいなのか、
それとも、エラークラス（HEWには無いかな）派生してるんでしょうか？
0122デフォルトの名無しさんNGNG
空の構造体投げればいいじゃないか
0123デフォルトの名無しさんNGNG
みんな自前のライブラリ・フレームワークと
自前のアプリ作る場合の例外って
どのクラスから派生してるの?
0124デフォルトの名無しさんNGNG
runtime_errorとassertだな。logic_errorは使わない。
0125デフォルトの名無しさんNGNG
>>122
なっとく。
エラークラスを作れない環境では、エラー構造体でcatchを分岐するわけね。
で、空じゃなくて、構造体のメンバーにエラーコードとかエラー文字列入れたり。
0126デフォルトの名無しさんNGNG
>>125
それ、エラークラス作れてるってことじゃないの。
0127125NGNG
>>126
あ、そか。

>>107 に例外の基底クラスを派生がマナーだけど、
C++だとメモリ管理不要って書いてあるね。

で、
{
　if (false == hogehogeAPI() {
　　THogeErrorClass HogeError;
　　throw HogeError;
　}
}
て感じ？
0128デフォルトの名無しさんNGNG
>>126
RTTIがないとcatchで分岐できませんからねえ。
0129127NGNG
で、クラスは空っぽで良いのかな。
class THogeErrorClass {};
0130デフォルトの名無しさんNGNG
使う側がそれでいいならいいよ。型が重要。

まあエラー原因文字くらい入れといた方が、
全部まとめて、

} catch (exception e) {
cerr << e.what() << endl;
exit(1);
}

出来て便利だけどね。
0131デフォルトの名無しさんNGNG
>>128
HEWなんかでも構造体にもRTTIあるんかなぁ。
こんなん書ける？
　try
　{
　}
　catch (stuct structhogehoge hogehoge)
　{　}
　catch (stuct structhoge hoge)
　{　}
　catch (...)
　{　}
0132デフォルトの名無しさんNGNG
>>131
・言語仕様
ANSI/ISO規格に基づき、例外処理やテンプレート機能もサポートしています。
http://www.hitachi-hec.co.jp/seihin-k/h8ccon/h8ccon01.htm

だから大丈夫なはずだけど、規格完全適合とは書いてないから、
使っている人に聞いてね。

ちなみにHEWって実行環境じゃなくて、開発環境なんじゃないの?
0133デフォルトの名無しさんNGNG
>>132
そのサポートしています、ってのが怪しいんだな。
規格の適合しています、と書けないわけだし。
構造化例外はオプション設定で「Use try, throw and catch of C++」をチェックさせるという後ろ向きなサポート。
0134デフォルトの名無しさんNGNG
後ろ向きなサポートなのは、ちゃんとサポートできてないからなんでしょ。
catch(...)でも例外がキャッチできずにabortいっちゃう事があって困った。
結局、例外使うのやめたんだけど。

ま、こっち側のミスの可能性は捨てきれないんだけど･･･。俺一人でやってるわけじゃないし。
0135デフォルトの名無しさんNGNG
>>134
え”ー。
構造化例外の良いところは複数人数で開発してても、正しいエラー処理が出来ることろでわ？
0136デフォルトの名無しさんNGNG
「構造化例外」と「C++における例外」って
Win32では明確に違うものなんだけど
ここで言ってるのは同じものなの？
0137デフォルトの名無しさんNGNG
構造化例外ってCの例外の事だろ？
C++例外はオブジェクト指向だし。
0138デフォルトの名無しさんNGNG
Cの例外というより、
WindowsとVC++独自のプラットフォーム/処理系依存の例外処理。
0139デフォルトの名無しさんNGNG
>>132のリンク先にはそんな情報は見当たらないから、
>>133(=>>135?)はC++例外と構造化例外がごっちゃになってるんじゃないの？
0140デフォルトの名無しさんNGNG
>>138
VCは関係無いんだけど、無知ですか？
0141デフォルトの名無しさんNGNG
まあまあ、C++例外と構造化例外の名前を間違えただけで、
制御構造はどっちも似てるし、この辺で元の議論へ。

構造化例外は例外オブジェクトなんて無いけど、throwみたいなもでしょ？
0142デフォルトの名無しさんNGNG
再入不可とかあったきがする
0143デフォルトの名無しさんNGNG
海外の組込み系クラスライブラリで、
Embedded C++に拘らず、メリットがあるからテンプレート（Embeddedには無い）なんかは使ってます、
だけど、
安全のためにthrowは使いません、て書いてあった。

catchしてれば良いだけでわ。
組込み的にthrowはどうやばいんだ？





組込み技術者がやヴぁい、というｵﾁﾀﾞﾀﾘｼﾃ
0144デフォルトの名無しさんNGNG
標準 C++ では、全ての例外が、logic_errorかruntime_errorのどちらかから派生するそうですね。
守るべきでしょうか。
クラスライブラリに依存しちゃうしかないんかな。
0145デフォルトの名無しさんNGNG
>>144
ライブラリなら、守ってたほうがありがたいと思う利用者が多いだろうな。

> クラスライブラリに依存しちゃうしかないんかな。
こっちは意味がわからん。
0146デフォルトの名無しさんNGNG
MFCとかVCLとかで定義されてる例外のことじゃないの
0147デフォルトの名無しさんNGNG
そういうクラスライブラリに依存しているコンポーネントなら、そっちから派生した方がいいかも。
でも、どっちがいいかは微妙だなー。

こういうふうに迷わないように、新しいライブラリを作るなら標準例外クラスから派生して欲しいな。
0148デフォルトの名無しさんNGNG
> 標準 C++ では、全ての例外が、
> logic_errorかruntime_errorのどちらかから派生するそうですね。
細かい突っ込みすると、class ios_base::failureは違うけどね。
class ios_base::failure: public exception
{
　[...]
};

> 守るべきでしょうか。
それって設計の問題なんで、こうすべきなんて答えは
ここで出てこないでしょう。あなたが導きださなければなりません。

まるで女のファッションみたいに、これって変かな？
なんてのと同じような感覚でこんな質問をするなら
もっとC++、さらにはプログラミングそのものの訓練が必要でしょう。
自分で設計上の結論を見出せないのですから。

などと突き放しては身もふたもないので、アドバイス。

たぶん、自分が用意しようとしている例外クラスがなんで必要なのか、
何をさせたいのかが見出せていないから、こういう質問になるのかと思います。

自問自答してみましょう。設計とは自問自答の繰り返しです。

> クラスライブラリに依存しちゃうしかないんかな。
んー、ちょっとわからんかった。ごめん。
0149デフォルトの名無しさんNGNG
>>144
> 守るべきでしょうか。

はい。
0150デフォルトの名無しさんNGNG
直接 exception から派生する奴はほかにもあるみたい。
bad_alloc
bad_cast
bad_exception
bad_typeid
0151デフォルトの名無しさんNGNG
libstdc++では、
$ egrep -r 'public exception' /usr/include/c++/3.3/*
/usr/include/c++/3.3/bits/ios_base.h: class failure : public exception
/usr/include/c++/3.3/exception: class bad_exception : public exception
/usr/include/c++/3.3/new: class bad_alloc : public exception
/usr/include/c++/3.3/stdexcept: class logic_error : public exception
/usr/include/c++/3.3/stdexcept: class runtime_error : public exception
/usr/include/c++/3.3/typeinfo: class bad_cast : public exception
/usr/include/c++/3.3/typeinfo: class bad_typeid : public exception
な感じ。
0152デフォルトの名無しさんNGNG
直接 exception から派生する奴が増えるのは、まぁ致し方ないとしても、
基底クラスがExceptionになったり、を何とかして欲しい。
ショウガナイから使ってるが、組み込み系では使えない。
組み込み系ではthrowを無視するコンパイラやライブラリが多いから、問題が表面化して無いが。
0153デフォルトの名無しさんNGNG
>>152
> 基底クラスがExceptionになったり、を何とかして欲しい。
何を問題としているのかわかりません。
0154デフォルトの名無しさんNGNG
>>153
catchするのが面倒なんじゃないの
0155デフォルトの名無しさんNGNG
やっぱ、exceptionに文字の付加情報が無かったのが、別クラスが出来た理由かな。
C++言語的には無い方が良いが、使うときには例外クラスに文字かコードは必須。
0156デフォルトの名無しさんNGNG
>>155
「文字の付加情報」と、 std::exception::what() は違うの？
0157デフォルトの名無しさんNGNG
whatって中身詰まってないし
0158デフォルトの名無しさんNGNG
詰まってないというか自分で入れろと
0159デフォルトの名無しさんNGNG
そこでvirtual関数をオーバーライドですよって、
詰めないといけないのは頭の中身なんじゃあ…
0160デフォルトの名無しさんNGNG
>>157-159
おまえらちゃんと会話しろよ。
0161デフォルトの名無しさんNGNG
>>156
あれ、exceptionにwhat()あったっけ？
自分の認識では、logic_error、runtime_error、とかの派生で初めてアクセスで出来たような。。。
0162デフォルトの名無しさんNGNG
>>161
what() は exception で virtual 関数として定義されている。
runtime_error 等は what() の戻り値がコンストラクタの引数として渡せる。
0163デフォルトの名無しさんNGNG
あ、そうだよね。やっぱ生のexceptionでは文字列詰めれない。

で、VC++でexceptionの派生をしたけど、かなり大変だったぞ。
他コンパイラで通るかも分からないしめんどー。
0164デフォルトの名無しさんNGNG
>>163
何が大変だったの？
ふつうにオーバーライドするだけじゃダメってこと？
0165デフォルトの名無しさんNGNG
アフォには何でも大変。
類推機能なしの脳には何でも初体験。
0166デフォルトの名無しさんNGNG
>>164
whatを使うために、こんなんなってたぞ↓

class HogeError : public exception {
public:
explicit HogeError(const string& _S): exception(""), _Str(_S) {}
virtual ~HogeError(){}
virtual const char *what() const{return (_Str.c_str()); }
protected:
virtual void _Doraise() const {_RAISE(*this); }
private:
string _Str;
};

組み込みコンパイラとクロスのソースとして使うことを想定してて、
下位のエラークラス派生を行わずにexceptionを派生した模様。
なんか無駄に終わったっぽいが。
0167デフォルトの名無しさんNGNG
>>164
exception("")って通るのか？
_Doraise/_RAISEは何やってんの？

標準の環境だけ想定すれば、
class HogeError : public std::runtime_error
{
public: explicit HogeError(std::string const& s) : runtime_error(s) {}
};
これでおしまいなんだが。

まぁ環境がちょっと特殊っぽいな。
組み込みを想定すると、 runtime_error は使っちゃいけなくなるのか？
0168デフォルトの名無しさんNGNG
説明足りなかったが、組み込みコンパイラは、
throwはサポートするがエラー派生クラスどころかSTLから無い。
「using namespace std;」は書けないし、実はusing句もサポートせず。
0169167NGNG
レス番間違えた。>>167は>>166宛て。
0170デフォルトの名無しさんNGNG
class HogeError : public exception {
　std::string str;
public:
　explicit HogeError(const std::string& s) : str(s) {}
　virtual const char *what() const { return str.data(); }
};

これだけで良いじゃないか。
そーいや、what()の戻り値ってc_str()じゃなくてdata()なんだよね。
0171デフォルトの名無しさんNGNG
>>168
それはC++の問題でも、ましてやVC++の問題でもないと思うんだが。
0172デフォルトの名無しさんNGNG
>>171
つか、このスレは例外処理を使うときの話であって、おまいの方が擦れ違い。

”C++の問題でも、ましてやVC++の問題でもない”からどーだって言うんだ。
0173デフォルトの名無しさんNGNG
>>170
多分それの方が短くて良いんだろうが、その内容にしても書くの面倒でない？
0174デフォルトの名無しさんNGNG
自分の環境の問題がC++の問題であるかのような発言をした>>155が悪い。
0175デフォルトの名無しさんNGNG
>>173
runtime_error使った>>167のやつでも面倒だと思う？
0176デフォルトの名無しさんNGNG
>>171
はぁ？

>>163 で、VC++でexceptionの派生をしたけど、かなり大変だったぞ。

VC++（C++）でexceptionの派生クラスを作るのは「かなり大変」
という話題から派生してるだけだけど、どこに問題が？

>>166 whatを使うために、こんなんなってたぞ

ご丁寧に、自分で勝手に煩雑な書き方をしていただけというオチまでついてるし。
0177デフォルトの名無しさんNGNG
>>175
自分的には、１行であるべきだと思う。
class HogaType_exception : public exception {} ;
class HogeType_exception : public exception {} ;
と沢山作っといて、で、最上位でdynamic_castして分岐させて。



ところで176は邪魔だな。
複雑なソースがあるから、このスレで何とか解決しようと思ってるんだが、何度も絡んでくるな。
レスは要らないと言ってるのに、もうレスすんあ。
0178デフォルトの名無しさんNGNG
exceptionとstringってどっちが先にできたの？
初期の頃って両方無かったような気がしたんだけど気のせい？
0179デフォルトの名無しさんNGNG
>>177
一行で書きたけりゃ、宣言と定義をわけたり、マクロを使ったり、いろいろできるだろ。勝手にやればいい。
最上位でdynamic_castって、catch並べて分岐しちゃダメなの？

> レスは要らないと言ってるのに
電波か？
0180デフォルトの名無しさんNGNG
179はスルー
0181デフォルトの名無しさんNGNG
電波だな。
176> ご丁寧に、自分で勝手に煩雑な書き方をしていただけというオチまでついてるし。

177の要件を満たす開発環境なんてねーし、何と比較してるんだよ。
そもそも、exceptionがあってruntimer_errorが無い環境ってのが想像不可能。
0182デフォルトの名無しさんNGNG
>>155>>161>>163>>166>>168>>172>>173>>177(=>>180?)
0183デフォルトの名無しさんNGNG
class HogeError : public exception {
　std::string str;
public:
　explicit HogeError(const std::string& s) : str(s) {}
　virtual const char *what() const { return str.data(); }
};

これをマクロにして、組み込みコンパイラがコンパイルエラーなんか出したときにゃ、ｶﾞｸﾌﾞﾙだな。
C++は好きだけどライブラリの中は結構追いにくい。
0184デフォルトの名無しさんNGNG
組み込み電波は放置しろ。
0185デフォルトの名無しさんNGNG
電波を連呼するなんて初心者だな。
連呼した方が勝ちってわけでもないのに。
0186デフォルトの名無しさんNGNG
>>170
一般には間違い。
例外クラスのコピーコンストラクタは例外を投げてはいけないので、
例えばこんな感じでラップする必要がある。
class HogeError : public exception {
　boost::shared_ptr<std::string> str;
public:
　explicit HogeError(const std::string& s)
    : str(new std::string(s)) {}
　virtual const char *what() const { return str->data(); }
};
stringが参照カウントで実装されているような処理系に依存していいならOK。
0187デフォルトの名無しさんNGNG
意外にC++のライブラリの中の記述はスッキリしないね。

STLの中の人が頑張ってくれてる、という考え方もあるが。
0188デフォルトの名無しさんNGNG
>>186
そこまでするんじゃ、やっぱりruntime_errorを継承するべきだな。
exceptionがokで、runtime_errorがNGなケースが思いつかないよ。
0189デフォルトの名無しさんNGNG
>exceptionがokで、runtime_errorがNGなケースが思いつかないよ。
HEW環境。
0190デフォルトの名無しさんNGNG
>>186
bad_allocはその辺回避するためにwhat()がないんでしょうね。
0191デフォルトの名無しさんNGNG
>>190
定数文字列返せばいいだけじゃん。
0192デフォルトの名無しさんNGNG
>>190
あるよ。
0193デフォルトの名無しさんNGNG
やっぱ、static の文字列しか駄目なんだよね。
ローカルのchar[]は駄目なんだよね。
0194デフォルトの名無しさんNGNG
>>193
C/C++ではローカルのchar[]を戻り値にできないのはあたりまえ。
0195デフォルトの名無しさんNGNG
じゃ、ローカルの:stringならＯＫ？
0196デフォルトの名無しさんNGNG
>>195
戻り値の型がstd::stringなら、どっちでもOK。
0197デフォルトの名無しさんNGNG
>>186
boostを使ったこと無いんですが、便利なんですか。
コンパイル通る環境はWin/POSIXくらいかな。
0198デフォルトの名無しさんNGNG
>>197
boostの中には様々なライブラリが入ってる。
使用できる環境もライブラリごとに違う。
一度使ってしまうと、使えない状況が苦痛になってしまうレベルのものが多い。
0199デフォルトの名無しさんNGNG
まるでヤク中だな。
つぎつぎと珍妙度の高いライブラリを
摂取していかざるを得ないなんて。
0200デフォルトの名無しさんNGNG
>>199
だれも「珍妙度が高い」とも「つぎつぎと摂取していかざるを得ない」とも言ってないわけだが。
電波か？
0201デフォルトの名無しさんNGNG
boostってドラフトの塊であって、いずれ纏まった形で標準ライブラリになるんだよね？
でないと困る。
0202デフォルトの名無しさんNGNG
まあ実装テクニックは珍妙度が高いと言わざるを得ないこともしばしば
0203デフォルトの名無しさんNGNG
>>201
そんな予定は無い
0204デフォルトの名無しさんNGNG
>>201
一部は標準ライブラリに含まれる予定。
全部ではない。
0205デフォルトの名無しさんNGNG
spiritが標準ライブラリに入ったらびっくり
0206デフォルトの名無しさんNGNG
STLやnamespaceも怪しい組み込み環境にboostなんてありえないな
0207デフォルトの名無しさんNGNG
>>206
boost::preprocessorならOKだよ。
0208デフォルトの名無しさんNGNG
やはり例外処理にはNestableExceptionが必須でしょ。

例外をListやVectorに蓄積する必要もなくなってかなりええねえ。

org.apache.commons.lang.exception.NestableException
http://www.jajakarta.org/commons/lang-2.0/ja/withoutPrimary/org/apache/commons/lang/exception/NestableException.html

org.apache.commons.lang.exception.NestableRuntimeException
http://www.jajakarta.org/commons/lang-2.0/ja/withoutPrimary/org/apache/commons/lang/exception/NestableRuntimeException.html
0209デフォルトの名無しさんNGNG

　ま　た　C#　の　パ　ク　リ　で　す　か　
0210デフォルトの名無しさんNGNG
>>208
せっかくだから最近の Windows にあるような Vectored Exception Handling も
あると良いのだけれども。オープンソースの世界だと需要がないのかな。
0211デフォルトの名無しさんNGNG
C#がjavaのコピーなんだからおあいこだべ
0212デフォルトの名無しさんNGNG
マルチスレッドでcatchしなかった場合、メインスレッドのcatchに通知されますか？

同様に、ITRONのタスクでthrowしてそのタスクでcatchしなかった場合、メインタスクのcatchにジャンプするんでしょうか？
0213デフォルトの名無しさんNGNG
nnnawakya-ne-daro
0214デフォルトの名無しさんNGNG
組み込み系って、うんこンパイラだから例外処理自体まともにうごかないってことはないの？
0215デフォルトの名無しさんNGNG
>>212
両方とも「しない」
0216デフォルトの名無しさんNGNG
ほしゅ
0217デフォルトの名無しさんNGNG
組み込み系な人たちにthrow/catchを教えるためのサイトを教えて下さいでつ。

cppファイル郡にcソースを平気で入れたり、コピペ・コーディング、といった程度でなく、
ソースファイルのコピー利用やプロトタイプ宣言をcソースに記述が平気な人たちが、
戻り値は駄目だ！これからはthrowだ！、という思いになるような説明ｷﾎﾞﾝ
0218デフォルトの名無しさんNGNG
>>217 ttp://pc5.2ch.net/test/read.cgi/tech/1068302657/105
0219デフォルトの名無しさんNGNG
>>217
標準ライブラリをリンクできない環境とかで、
例外処理ルーチンを自分で書ければ例外使えるんだけど、なんとかならん？
0220デフォルトの名無しさんNGNG
>>218
ﾏﾆｱｯｸだね
0221デフォルトの名無しさんNGNG
■ このスレッドは過去ログ倉庫に格納されています