Cの小さなエラーごとにチェックする必要がありますか？

優れたプログラマーとして、プログラムのすべての結果を処理する堅牢なコードを作成する必要があります。ただし、エラーが発生すると、Cライブラリのほとんどすべての関数は0、-1、またはNULLを返します。

たとえば、ファイルを開こうとするときなど、エラーチェックが必要であることは明らかです。しかし、私はしばしば、printfまたはmalloc必要だと感じないからといって、関数のエラーチェックを無視します。

if(fprintf(stderr, "%s", errMsg) < 0){
    perror("An error occurred while displaying the previous error.");
    exit(1);
}

特定のエラーを無視するのは良い習慣ですか、それともすべてのエラーを処理するより良い方法がありますか？

一般に、コードは適切な場合には例外的な条件に対処する必要があります。はい、これはあいまいな声明です。

ソフトウェア例外処理を備えた高レベル言語では、これは「実際に何かを行うことができるメソッドで例外をキャッチする」とよく言われます。ファイルエラーが発生した場合は、ユーザーに「ファイルをディスクに保存できませんでした」と実際に伝えることができるUIコードにスタックをバブルさせます。例外メカニズムは「小さなエラー」を効果的に飲み込み、適切な場所で暗黙的に処理します。

Cでは、そのような贅沢はありません。エラーを処理する方法はいくつかあります。その一部は言語/ライブラリ機能であり、一部はコーディング方法です。

特定のエラーを無視するのは良い習慣ですか、それともすべてのエラーを処理するより良い方法がありますか？

特定のエラーを無視しますか？多分。たとえば、標準出力への書き込みが失敗しないと仮定することは合理的です。失敗した場合、とにかくユーザーにどのように伝えますか？はい、特定のエラーを無視するか、それらを防ぐために防御的にコーディングすることをお勧めします。たとえば、除算する前にゼロをチェックします。

すべてのエラー、または少なくともほとんどのエラーを処理する方法があります。

1. エラー処理には、gotoに似たジャンプを使用できます。ソフトウェアの専門家の間では議論の多い問題ですが、特に組み込みのパフォーマンスクリティカルなコード（Linuxカーネルなど）で有効に使用されています。

2. カスケードifs：

   if (!<something>) {
     printf("oh no 1!");
     return;
   }
   if (!<something else>) {
     printf("oh no 2!");
     return;
   }
   

3. ファイルを開く、または作成するなど、最初の条件をテストし、その後の操作が成功すると仮定します。

堅牢なコードは適切であり、エラーをチェックして処理する必要があります。コードに最適な方法は、コードの機能、障害の重大度などに依存し、真に答えることができるのはあなただけです。ただし、これらのメソッドは、さまざまなオープンソースプロジェクトでバトルテストされ、使用されており、実際のコードでエラーをチェックする方法を確認できます。

ただし、エラーが発生すると、Cライブラリのほとんどすべての関数は0、-1、またはNULLを返します。

はい、しかし、どの関数を呼び出したか知っていますか？

実際には、エラーメッセージに入れることができる多くの情報があります。呼び出された関数、それを呼び出した関数の名前、渡されたパラメーター、および関数の戻り値がわかります。これは、非常に有益なエラーメッセージについての十分な情報です。

すべての関数呼び出しでこれを行う必要はありません。ただし、「以前のエラーを表示中にエラーが発生しました」というエラーメッセージが初めて表示されたとき、本当に必要な情報が有用な情報だった場合、そのエラーメッセージは最後に表示されます。エラーメッセージを参考にして、問題のトラブルシューティングに役立ててください。

TLDR; エラーを無視することはほとんどありません。

C言語には、各ライブラリ開発者が独自のソリューションを実装するための優れたエラー処理機能がありません。最近の言語には例外が組み込まれているため、この特定の問題の処理がはるかに簡単になります。

しかし、Cにこだわっているときは、そのような特典はありません。残念ながら、失敗する可能性のある関数を呼び出すたびに、単に価格を支払う必要があります。そうしないと、意図せずにメモリ内のデータを上書きするなど、はるかに悪い結果になります。したがって、一般的なルールとして、常にエラーをチェックする必要があります。

返品を確認しないとfprintf、バグを残してしまう可能性が高く、最良の場合、ユーザーが期待することは行われず、最悪の場合、フライト中に全体が爆発します。そのように自分自身を損なう言い訳はありません。

ただし、C開発者としては、コードの保守を容易にすることもあなたの仕事です。したがって、エラーがアプリケーションの全体的な動作に脅威を与えない場合（およびその場合のみ）、明確にするためにエラーを無視しても安全です。。

これを行うのと同じ問題です。

try
{
    run();
} catch (Exception) {
    // comments expected here!!!
}

空のcatchブロック内に適切なコメントがないことを確認した場合、これは確かに問題です。への呼び出しがmalloc()100％の時間で正常に実行されると考える理由はありません。

質問は実際には言語固有ではなく、ユーザー固有です。ユーザーの観点から質問を考えてください。ユーザーは、コマンドラインでプログラムの名前を入力してEnterキーを押すなどの操作を行います。ユーザーは何を期待していますか？何かがうまくいかなかった場合、彼らはどのように知ることができますか？エラーが発生した場合、彼らは仲裁する余裕がありますか？

多くのタイプのコードでは、このようなチェックはやり過ぎです。ただし、原子炉用のコードなど、信頼性の高い安全性が重要なコードでは、病理学的エラーチェックと計画された回復パスが日常業務の一部です。「Xに障害が発生するとどうなりますか？どうすれば安全な状態に戻ることができますか？」ビデオゲームなどの信頼性の低いコードでは、エラーチェックをはるかに少なくして逃げることができます。

別の同様のアプローチは、エラーをキャッチすることで状態を実際にどれだけ改善できるかということです。例外を誇らしげにキャッチするC ++プログラムの数を数えることはできませんが、例外を実際に処理する方法がわからなかったために再スローするだけですが、例外処理を行うことになっていることはわかっていました。そのようなプログラムは、余分な努力から何も得られませんでした。エラーコードを単にチェックしないよりも、実際に状況をうまく処理できると思われるエラーチェックコードのみを追加してください。そうは言っても、C ++には、例外処理中に発生する例外を処理するための特定のルールがあり、それらをより意味のある方法でキャッチします（そして、それにより、自分用に構築した葬儀のpyrが点灯することを確認するためにterminate（）を呼び出すことを意味します）その適切な栄光で）

どのくらい病理学的になりますか？私は、「SafetyBool」を定義するプログラムを作成しました。そのSafetyBoolの真と偽の値は、1と0の均等な分布を持つように慎重に選択されました。トレースが壊れるなど）、ブール値が誤って解釈されることはありませんでした。言うまでもなく、私はこれが古いプログラムで使用される汎用プログラミング手法であるとは主張しません。

• さまざまな安全要件により、さまざまなレベルの正確さが求められます。航空または自動車制御ソフトウェアでは、すべての戻り値がチェックされます。cf。MISRA.FUNC.UNUSEDRET。マシンを決して離れることのない、概念の簡単な証明で、おそらくそうではありません。
• コーディングには時間がかかります。安全性が重要ではないソフトウェアの無関係なチェックが多すぎると、他の場所で費やす労力が増えます。しかし、品質とコストのスイートスポットはどこですか？それはデバッグツールとソフトウェアの複雑さに依存します。
• エラー処理により、制御フローがわかりにくくなり、新しいエラーが発生する場合があります。私は、少なくともエラーを報告するRichard "network" Stevensのラッパー関数がとても好きです。
• エラー処理がパフォーマンスの問題になることはまれです。しかし、ほとんどのCライブラリの呼び出しには非常に時間がかかるため、戻り値をチェックするコストは計り知れないほど小さいです。

少し抽象的な抽象的質問。そして、それは必ずしもC言語のためではありません。

大規模なプログラムの場合、抽象化レイヤーがあります。おそらく、エンジンの一部、ライブラリ、またはフレームワーク内です。その層は、有効なデータを取得したり、出力は、いくつかのデフォルト値となり、天候を気にしないでしょう：0、-1、nullなど

次に、抽象レイヤーへのインターフェイスとなるレイヤーがあり、多くのエラー処理や、依存関係の注入、イベントリスニングなどのその他の処理を行います。

後で、実際のルールを設定して出力を処理する具体的な実装レイヤーができます。

したがって、これに対する私の見解は、コードの一部からエラー処理を完全に除外した方がよい場合があるということです。そして、出力を評価してエラーを指すプロセッサーを用意します。

これは主に、コードを読みやすくし、スケーラビリティを向上させる責任を分離するために行われます。

一般に、そのエラー状態をチェックしない正当な理由がない限り、そうすべきです。エラー状態をチェックしない理由として考えられる唯一の正当な理由は、失敗した場合に意味のある何かを実行できない可能性があることです。ただし、実行可能なオプションが常に1つあるため、これは満たすのが非常に難しいバーです。