私の質問は、ほとんどの開発者がエラー処理、例外、またはエラーリターンコードに対して何を好むかということです。言語（または言語族）固有であり、なぜ一方を他方よりも好むのかを教えてください。
私は好奇心からこれを求めています。個人的には、エラーリターンコードの方が爆発性が低く、必要がない場合にユーザーコードに例外パフォーマンスペナルティを支払うように強制しないため、私はエラーリターンコードを好みます。
更新：すべての回答に感謝します！私は例外を除いてコードフローの予測不可能性が嫌いですが、言わなければなりません。リターンコード（およびその兄のハンドル）に関する答えは、コードに多くのノイズを追加します。
回答:
C ++はRAIIに基づいています。
失敗、戻り、またはスローする可能性のあるコード（つまり、ほとんどの通常のコード）がある場合は、ポインターをスマートポインターでラップする必要があります（オブジェクトをスタックに作成しない非常に正当な理由があると仮定します）。
それらは冗長であり、次のようなものに発展する傾向があります。
if(doSomething())
{
if(doSomethingElse())
{
if(doSomethingElseAgain())
{
// etc.
}
else
{
// react to failure of doSomethingElseAgain
}
}
else
{
// react to failure of doSomethingElse
}
}
else
{
// react to failure of doSomething
}
結局のところ、あなたのコードは識別された命令のコレクションです（私はこの種のコードを本番コードで見ました）。
このコードは次のように翻訳できます。
try
{
doSomething() ;
doSomethingElse() ;
doSomethingElseAgain() ;
}
catch(const SomethingException & e)
{
// react to failure of doSomething
}
catch(const SomethingElseException & e)
{
// react to failure of doSomethingElse
}
catch(const SomethingElseAgainException & e)
{
// react to failure of doSomethingElseAgain
}
これはきれいに別々のコードとエラー処理、できることが良いです事。
1つのコンパイラからのあいまいな警告（「phjr」のコメントを参照）がない場合は、簡単に無視できます。
上記の例では、誰かがその可能性のあるエラーを処理するのを忘れていると仮定します（これは起こります...）。「返された」場合、エラーは無視され、後で爆発する可能性があります（つまり、NULLポインター）。同じ問題は例外なく発生しません。
エラーは無視されません。爆発したくない場合もありますが...慎重に選択する必要があります。
次の関数があるとしましょう。
呼び出された関数の1つが失敗した場合、doTryToDoSomethingWithAllThisMessが返されるタイプは何ですか？
演算子はエラーコードを返すことはできません。C ++コンストラクターもできません。
上記の点の当然の結果。書きたい場合はどうすればよいですか？
CMyType o = add(a, multiply(b, c)) ;
戻り値はすでに使用されているため、できません（場合によっては変更できないこともあります）。したがって、戻り値が最初のパラメータになり、参照として送信されます...またはそうではありません。
例外の種類ごとに異なるクラスを送信できます。リソースの例外（つまり、メモリ不足）は軽いはずですが、それ以外は必要なだけ重い可能性があります（Java例外がスタック全体を提供するのが好きです）。
その後、各キャッチを特殊化できます。
通常、エラーを非表示にしないでください。再スローしない場合は、少なくとも、エラーをファイルに記録し、メッセージボックスを開きます...
例外の問題は、それらを使いすぎると、試行/キャッチでいっぱいのコードが生成されることです。しかし、問題は他の場所にあります。STLコンテナを使用して自分のコードを試す/キャッチするのは誰ですか？それでも、これらのコンテナは例外を送信できます。
もちろん、C ++では、例外をデストラクタから出させないでください。
それらがひざまずいてスレッドを引き出す前に、またはWindowsメッセージループ内で伝播する前に、必ずそれらをキャッチしてください。
だから私は解決策は何かが起こってはならないときに投げることだと思います。そして、何かが発生する可能性がある場合は、戻りコードまたはパラメーターを使用して、ユーザーがそれに反応できるようにします。
だから、唯一の質問は「起こってはならないことは何ですか？」です。
それはあなたの機能の契約に依存します。関数がポインターを受け入れるが、ポインターがNULL以外でなければならないと指定した場合、ユーザーがNULLポインターを送信したときに例外をスローしても問題ありません（C ++では、関数の作成者が代わりに参照を使用しなかった場合に問題が発生します）。ポインタの、しかし...）
時々、あなたの問題はあなたがエラーを望まないということです。例外またはエラー戻りコードを使用することはクールですが...あなたはそれについて知りたいです。
私の仕事では、一種の「アサート」を使用します。構成ファイルの値に応じて、デバッグ/リリースのコンパイルオプションに関係なく、次のようになります。
これにより、開発とテストの両方で、ユーザーは問題が検出されたときに正確に特定できます。問題が検出された後ではありません（一部のコードが戻り値を気にする場合やキャッチ内）。
レガシーコードに追加するのは簡単です。例えば：
void doSomething(CMyObject * p, int iRandomData)
{
// etc.
}
次のような種類のコードを導きます。
void doSomething(CMyObject * p, int iRandomData)
{
if(iRandomData < 32)
{
MY_RAISE_ERROR("Hey, iRandomData " << iRandomData << " is lesser than 32. Aborting processing") ;
return ;
}
if(p == NULL)
{
MY_RAISE_ERROR("Hey, p is NULL !\niRandomData is equal to " << iRandomData << ". Will throw.") ;
throw std::some_exception() ;
}
if(! p.is Ok())
{
MY_RAISE_ERROR("Hey, p is NOT Ok!\np is equal to " << p->toString() << ". Will try to continue anyway") ;
}
// etc.
}
（デバッグ時にのみアクティブになる同様のマクロがあります）。
本番環境では、構成ファイルが存在しないため、クライアントにこのマクロの結果が表示されることはありません...ただし、必要に応じて簡単にアクティブ化できます。
リターンコードを使用してコーディングする場合、失敗に備えることになり、テストの要塞が十分に安全であることを願っています。
例外を使用してコーディングする場合、コードが失敗する可能性があることを知っており、通常、コード内の選択された戦略的位置にカウンターファイアキャッチを配置します。しかし、通常、あなたのコードは「それがしなければならないこと」よりも「私が恐れていることが起こる」ことに関するものです。
しかし、コーディングするときは、自由に使える最高のツールを使用する必要があり、「エラーを隠さないで、できるだけ早く表示する」という場合もあります。上で話したマクロはこの哲学に従います。
if( !doSomething() ) { puts( "ERROR - doSomething failed" ) ; return ; // or react to failure of doSomething } if( !doSomethingElse() ) { // react to failure of doSomethingElse() }
doSomething(); doSomethingElse(); ...if / while / etcを追加する必要がある場合は、まだ良いと思います。通常の実行目的のステートメントでは、if / while / etcと混合したくありません。例外的な目的で追加されたステートメント...そして、例外の使用に関する実際のルールは、キャッチではなくスローであるため、try / catchステートメントは通常侵襲的ではありません。
私は実際に両方を使用しています。
既知のエラーの可能性がある場合は、リターンコードを使用します。それが可能であり、発生することがわかっているシナリオである場合は、返送されるコードがあります。
例外は、私が予期していないことにのみ使用されます。
フレームワーク設計ガイドラインの「例外」というタイトルの第7章によると、再利用可能な.NETライブラリの規則、イディオム、およびパターン、C＃などのオブジェクト指向フレームワークで戻り値に対して例外を使用する必要がある理由について多くの理由が示されています。
おそらくこれが最も説得力のある理由です（179ページ）：
「例外はオブジェクト指向言語とうまく統合されます。オブジェクト指向言語は、オブジェクト指向以外の言語の関数によって課されないメンバー署名に制約を課す傾向があります。たとえば、コンストラクター、演算子のオーバーロード、およびプロパティの場合、開発者は戻り値に選択肢がありません。このため、オブジェクト指向フレームワークの戻り値ベースのエラー報告を標準化することはできません。例外など、メソッドシグネチャの範囲外のエラー報告方法。唯一の選択肢です。」
私の好み（C ++とPython）は、例外を使用することです。言語が提供する機能により、例外を発生させ、キャッチし、（必要に応じて）再スローするための明確に定義されたプロセスが作成され、モデルが見やすく、使いやすくなります。概念的には、特定の例外を名前で定義し、それに付随する追加情報を含めることができるという点で、戻りコードよりもクリーンです。戻りコードを使用すると、エラー値のみに制限されます（ReturnStatusオブジェクトなどを定義する場合を除く）。
作成しているコードがタイムクリティカルでない限り、スタックの巻き戻しに関連するオーバーヘッドは、心配するほど重要ではありません。
例外は、予期しないことが発生した場合にのみ返されます。
例外のもう1つのポイントは、歴史的に、戻りコードは本質的に独自のものであり、成功を示すためにC関数から0が返される場合もあれば、-1が返される場合もあります。それらが列挙されている場合でも、列挙はあいまいになる可能性があります。
例外は、より多くの情報を提供することもでき、具体的には「何かがうまくいかなかった、これが何であるか、スタックトレースとコンテキストのサポート情報」を詳しく説明します。
そうは言っても、適切に列挙されたリターンコードは、既知の一連の結果に役立つ可能性があります。単純な「関数のn個の結果がここにあり、このように実行されただけです」
Javaでは、（次の順序で）使用します。
契約による設計（失敗する可能性のあるものを試す前に、前提条件が満たされていることを確認します）。これはほとんどのものをキャッチし、私はこれのエラーコードを返します。
作業中（および必要に応じてロールバックの実行中）にエラーコードを返す。
例外ですが、これらは予期しないことにのみ使用されます。
assert常にアサーションを使用して実行しない限り、本番コードの問題をキャッチしないという点で、Cのものと同じ問題があります。私は、開発中にキャッチ問題への道としてアサーションを参照する傾向があるが、唯一の（例えば、定数、とのものなどないアサート一貫主張またはだろうもののためではない変数や、実行時に変更することができない何かを持つもの）。
リターンコードは、ほぼ毎回「PitofSuccess」テストに失敗します。
パフォーマンスについて：
The Pragmatic Programmerから得た素晴らしいアドバイスは、「プログラムは例外をまったく使用せずにすべての主要機能を実行できるはずです」というものでした。
これについては少し前にブログ記事を書きました。
例外をスローすることによるパフォーマンスのオーバーヘッドは、決定に影響を与えるべきではありません。結局のところ、正しく実行している場合、例外は例外です。
リターンコードは、コード全体で次のパターンが発生するため、嫌いです。
CRetType obReturn = CODE_SUCCESS;
obReturn = CallMyFunctionWhichReturnsCodes();
if (obReturn == CODE_BLOW_UP)
{
// bail out
goto FunctionExit;
}
すぐに、4つの関数呼び出しで構成されるメソッド呼び出しが12行のエラー処理で膨れ上がります。そのうちのいくつかは決して起こりません。ifとswitchのケースがたくさんあります。
例外をうまく使用すると、例外がよりクリーンになります...例外イベントを通知するために..その後、実行パスを続行できなくなります。多くの場合、エラーコードよりも説明的で情報が豊富です。
メソッド呼び出しの後に複数の状態があり、異なる方法で処理する必要がある場合（例外的なケースではありません）、エラーコードまたは出力パラメーターを使用します。個人的には、これはまれであることがわかりました。
私は「パフォーマンスペナルティ」の反論について少し探しました。C++ / COMの世界ではもっとですが、新しい言語では、違いはそれほど大きくないと思います。いずれにせよ、何かが爆発したとき、パフォーマンスの懸念はバックバーナーに追いやられます:)
適切なコンパイラまたはランタイム環境の例外があれば、重大なペナルティは発生しません。これは、多かれ少なかれ、例外ハンドラーにジャンプするGOTOステートメントに似ています。また、ランタイム環境（JVMなど）によって例外がキャッチされると、バグの切り分けと修正がはるかに簡単になります。私はいつでもCのセグメンテーション違反に対してJavaのNullPointerExceptionを取ります。
finally、スタックに割り当てられたオブジェクトのブロックとデストラクタを処理するには、スタックを巻き戻す必要があります。
簡単なルールセットがあります。
1）直接の発信者が反応すると予想されるものにはリターンコードを使用します。
2）範囲が広く、呼び出し元の何レベルも上のレベルで処理されることが合理的に予想されるエラーには例外を使用します。これにより、エラーの認識が多くのレイヤーに浸透する必要がなくなり、コードがより複雑になります。
Javaでは、チェックされていない例外のみを使用しました。チェックされた例外は、別の形式の戻りコードになります。私の経験では、メソッド呼び出しによって「返される」可能性のあるものの二重性は、一般に、ヘルプよりも障害でした。
例外的な状況と例外的でない状況の両方で、Pythonで例外を使用します。
エラー値を返すのではなく、例外を使用して「要求を実行できませんでした」ことを示すことができると便利なことがよくあります。これは、戻り値が任意のNoneやNotFoundSingletonなどではなく、正しい型であることを/常に/知っていることを意味します。これは、戻り値の条件の代わりに例外ハンドラーを使用することを好む良い例です。
try:
dataobj = datastore.fetch(obj_id)
except LookupError:
# could not find object, create it.
dataobj = datastore.create(....)
副作用として、datastore.fetch（obj_id）を実行すると、戻り値がNoneかどうかを確認する必要がなくなり、すぐに無料でエラーが発生します。これは、「プログラムは例外をまったく使用せずにすべての主要機能を実行できるはずです」という議論に反しています。
これは、競合状態の影響を受けないファイルシステムを処理するためのコードを記述するために、例外が「例外的に」役立つ別の例です。
# wrong way:
if os.path.exists(directory_to_remove):
# race condition is here.
os.path.rmdir(directory_to_remove)
# right way:
try:
os.path.rmdir(directory_to_remove)
except OSError:
# directory didn't exist, good.
pass
2つではなく1つのシステムコール、競合状態なし。これは、ディレクトリが存在しないよりも多くの状況でOSErrorで失敗することは明らかであるため、悪い例ですが、厳密に制御された多くの状況では「十分」なソリューションです。
リターンコードはコードノイズを増やすと思います。たとえば、リターンコードがあるため、COM / ATLコードの外観は常に嫌いでした。コードのすべての行に対してHRESULTチェックが必要でした。エラーリターンコードは、COMのアーキテクトが下した悪い決定の1つだと思います。コードの論理的なグループ化が困難になるため、コードレビューが困難になります。
行ごとに戻りコードを明示的にチェックする場合のパフォーマンスの比較についてはよくわかりません。
大きな違いの1つは、例外によってエラーの処理が強制されるのに対し、エラー戻りコードはチェックされないままになる可能性があることです。
エラーリターンコードを頻繁に使用すると、次の形式のifテストが多数含まれる非常に醜いコードが発生する可能性があります。
if(function(call) != ERROR_CODE) {
do_right_thing();
}
else {
handle_error();
}
個人的には、呼び出し元のコードが対処する必要がある、または対処しなければならないエラーには例外を使用し、何かを返すことが実際に有効で可能である「予期される失敗」にはエラーコードのみを使用することを好みます。
戻りコードよりも例外を優先する理由はたくさんあります。
例外はエラー処理ではありません、IMO。例外はそれだけです。あなたが予期していなかった例外的なイベント。私が言うように注意して使用してください。
エラーコードは問題ありませんが、メソッドから404または200を返すのは悪いです、IMO。代わりに列挙型（.Net）を使用してください。これにより、コードが読みやすくなり、他の開発者にとって使いやすくなります。また、番号と説明の表を維持する必要はありません。
また; try-catch-finallyパターンは、私の本ではアンチパターンです。try-finallyは良いこともあり、try-catchも良いこともありますが、try-catch-finallyは決して良いことではありません。try-finallyは、多くの場合、「using」ステートメント（IDisposeパターン）に置き換えることができます。これは、より優れたIMOです。そして、処理できる例外を実際にキャッチするトライキャッチが適切です。または、これを行う場合は次のようになります。
try{
db.UpdateAll(somevalue);
}
catch (Exception ex) {
logger.Exception(ex, "UpdateAll method failed");
throw;
}
例外をバブルし続ける限り、問題ありません。別の例はこれです：
try{
dbHasBeenUpdated = db.UpdateAll(somevalue); // true/false
}
catch (ConnectionException ex) {
logger.Exception(ex, "Connection failed");
dbHasBeenUpdated = false;
}
ここで私は実際に例外を処理します。更新メソッドが失敗したときにtry-catchの外で行うことは別の話ですが、私の主張は正しいと思います。:)
それでは、なぜtry-catch-finallyはアンチパターンなのですか？理由は次のとおりです。
try{
db.UpdateAll(somevalue);
}
catch (Exception ex) {
logger.Exception(ex, "UpdateAll method failed");
throw;
}
finally {
db.Close();
}
dbオブジェクトがすでに閉じられている場合はどうなりますか？新しい例外がスローされ、処理する必要があります。これの方が良い：
try{
using(IDatabase db = DatabaseFactory.CreateDatabase()) {
db.UpdateAll(somevalue);
}
}
catch (Exception ex) {
logger.Exception(ex, "UpdateAll method failed");
throw;
}
または、dbオブジェクトがIDisposableを実装していない場合は、次のようにします。
try{
try {
IDatabase db = DatabaseFactory.CreateDatabase();
db.UpdateAll(somevalue);
}
finally{
db.Close();
}
}
catch (DatabaseAlreadyClosedException dbClosedEx) {
logger.Exception(dbClosedEx, "Database connection was closed already.");
}
catch (Exception ex) {
logger.Exception(ex, "UpdateAll method failed");
throw;
}
それはとにかく私の2セントです！:)
例外について私が恐れていることの1つは、例外をスローするとコードフローが台無しになることです。たとえば、あなたがする場合
void foo()
{
MyPointer* p = NULL;
try{
p = new PointedStuff();
//I'm a module user and I'm doing stuff that might throw or not
}
catch(...)
{
//should I delete the pointer?
}
}
またはさらに悪いことに、私が持ってはいけないものを削除したが、残りのクリーンアップを行う前にキャッチするために投げられた場合はどうなりますか。投げることは貧しいユーザーIMHOに大きな重みを置きました。
例外と戻りコードの引数の私の一般的なルール：
リターンコードが例外ほど醜いものではないと思います。例外を除いて、try{} catch() {} finally {}リターンコードと同様にどこにありますかif(){}。私は以前、投稿に記載されている理由で例外を恐れていました。ポインタをクリアする必要があるかどうかわかりませんが、何がありますか。しかし、リターンコードに関しても同じ問題があると思います。問題の関数/メソッドに関する詳細を知らない限り、パラメーターの状態はわかりません。
とにかく、可能であればエラーを処理する必要があります。戻りコードを無視してプログラムをセグメンテーション違反させるのと同じくらい簡単に、例外をトップレベルに伝播させることができます。
結果の値（列挙？）と例外的な場合の例外を返すというアイデアが好きです。
失敗が例外的であるかどうかを呼び出し元が判断できるため、一般的にリターンコードを好みます。
このアプローチは、Elixir言語では一般的です。
# I care whether this succeeds. If it doesn't return :ok, raise an exception.
:ok = File.write(path, content)
# I don't care whether this succeeds. Don't check the return value.
File.write(path, content)
# This had better not succeed - the path should be read-only to me.
# If I get anything other than this error, raise an exception.
{:error, :erofs} = File.write(path, content)
# I want this to succeed but I can handle its failure
case File.write(path, content) do
:ok => handle_success()
error => handle_error(error)
end
リターンコードを使用すると、ネストされたifステートメントが多数発生する可能性があると言われていますが、より適切な構文で処理できます。Elixirでは、このwithステートメントを使用すると、一連のハッピーパスの戻り値を障害から簡単に分離できます。
with {:ok, content} <- get_content(),
:ok <- File.write(path, content) do
IO.puts "everything worked, happy path code goes here"
else
# Here we can use a single catch-all failure clause
# or match every kind of failure individually
# or match subsets of them however we like
_some_error => IO.puts "one of those steps failed"
_other_error => IO.puts "one of those steps failed"
end
Elixirには、例外を発生させる機能がまだあります。最初の例に戻ると、ファイルに書き込めない場合は、これらのいずれかを実行して例外を発生させることができます。
# Raises a generic MatchError because the return value isn't :ok
:ok = File.write(path, content)
# Raises a File.Error with a descriptive error message - eg, saying
# that the file is read-only
File.write!(path, content)
呼び出し元として、書き込みが失敗した場合にエラーを発生させたいことがわかっている場合は、のFile.write!代わりに呼び出すことを選択できますFile.write。またはFile.write、失敗の考えられる理由をそれぞれ異なる方法で呼び出して処理することを選択できます。
もちろんrescue、必要に応じて例外が発生する可能性は常にあります。しかし、有益な戻り値を処理することと比較すると、それは私には厄介に思えます。関数呼び出しが失敗する可能性がある、または失敗するはずであることがわかっている場合、その失敗は例外的なケースではありません。