まえがき
この記事は、記事に対する反応です： C ++ 2aのエラー処理はどうなりますか 。 各段落の後、かゆみを感じ、治癒した傷が開き、出血し始めました。 書いたものを自分の心に近づけすぎるかもしれません。 しかし、21世紀にC ++プログラマーが示す近視眼と非識字については、ただ遠howえしたいだけです。 そして、最初でもそうではありません。
始めましょう。
分類
従来、プログラム内のすべてのエラー状況は、2つの大きなグループに分けることができます。
- 致命的なエラー。
- 致命的ではない、または予期されるエラー。
私は今、障害を見つけます。 しかし、致命的なエラー-ある意味で予想されています。 私たちは、メモリを通過することがしばしば転倒につながると期待しますが、転倒につながるとは限りません。 そして、これは予想されていることですね。 分類が導入されると、一貫性をチェックすることが常に可能になります。
しかし、それは頻繁な微妙な間違いです。
致命的なエラーを見てみましょう。
0による除算 。 このエラーが致命的なのはなぜだろうか？ この場合、例外をスローし、さらに処理するためにキャッチしたいと思います。 なぜ彼女は致命的ですか？ 自分のプログラムの特定の動作が私に課されているのはなぜですか、私はそれを何らかの方法で影響することはできませんか？ C ++は柔軟性についてではなく、言語がプログラマーに向けられているという事実についてですか？ しかし...
NULLポインターの逆参照 。 私はすぐにJavaを思い出します。処理できるNullPointerException
があります。 PocoライブラリNullPointerException
もあります！ それでは、なぜ標準的な開発者が聴覚障害者ミュートの粘り強さで同じマントラを繰り返すのでしょうか？
一般に、なぜこのトピックを始めたのですか？ これは非常に重要であり、エラー処理に関する開発者の理解を明らかにするだけです。 これはエラー処理そのものではなく、重要なアクションの前置きです。 それは常にアプリケーションの信頼性、フォールトトレランス、そして時には非常にまれで絶滅の危機にあるタイプのプログラムであり、トランザクションの一貫した動作についてです。
この側面では、ゼロによる除算とポインターの間接参照に関するすべての論争は、パンくずを求めて鳥の闘争のように見えます。 確かに重要なプロセス。 しかし、鳥の観点からのみ。
運命論とその不在への分割に戻りましょう...私は簡単な質問から始めましょう。ネットワーク経由で間違ったデータを受信した場合、これは致命的なエラーですか？
シンプルで正しい答え：依存します。 ほとんどの場合、これは致命的なエラーではなく、ネットワーク経由で受信したすべてのデータを検証し、データが正しくない場合は4xxを返す必要があることは明らかです。 クラッシュする必要がある場合はありますか？ そして、例えばSMSが来るように、野生の遠howえでcrash落しました。 はい、1つではありません。
あります。 私の主題分野から例を挙げることができます：分散コンセンサスアルゴリズム。 ノードは、別のノードからの一連の変更からのハッシュを含む応答を受け取ります。 そして、このハッシュはローカルのものとは異なります。 これは、何かがうまくいかなかったことを意味し、さらに実行を続けることは単に危険です。データがまだ分岐していない場合、分岐する可能性があります。 サービスの可用性がその一貫性よりも重要でない場合に発生します。 この場合、誰もが周りの声を聞くことができるように、私たちはfallりながら倒れる必要があります。 つまり ネットワーク経由でデータを受信し、検証し、落ちました。 私たちにとって、この間違いは致命的ではありません。 このエラーは予想されますか？ ええ、はい、検証付きでコードを書きました。 その反対を言うのは愚かです。 その後はプログラムを継続したくないだけです。 手動による介入が必要で、自動化は機能しませんでした。
運命論の選択
エラー処理で最も明白なことは、致命的なものとそうでないものを決定することです。 しかし、すべてのプログラマーは、開発活動全体を通してこの質問を自分に尋ねます。 したがって、彼はどういうわけかこの質問に答えます。 正しい理由は、何らかの理由で練習から得られます。
ただし、これは氷山の目に見える部分にすぎません。 深部には、はるかに大きな問題があります。 完全な深さを理解するには、簡単なタスクを設定し、それに答える必要があります。
チャレンジ 。 何かの枠組みを作ります。
すべてがシンプルです。 たとえば、ネットワーク相互作用のフレームワークを作成します。 またはJSONを解析します。 または、最悪の場合、XML。 問題はすぐに発生します：しかし、ソケットからエラーが発生した場合-それは致命的なエラーかどうか？ 言い換えると、例外をスローするか、エラーを返す必要がありますか？ これは例外的な状況ですか？ または、 std::optional
を返すことができstd::optional
か？ または修道女？ （^ 1）
逆説的な結論は、フレームワーク自体がこの質問に答えることができないということです。 それを使用するコードのみが知っています。 私の意見では、 boost.asioライブラリが両方のオプションを使用しているのはそのためです。 コードの作成者と適用されたロジックの個人的な好みに応じて、エラー処理の1つまたは別の方法を選択できます。 最初は、このアプローチに少し戸惑いましたが、時間が経つにつれて、このアプローチの柔軟性に染みつきました。
ただし、これだけではありません。 最悪の事態が来ることです。 ここではアプリケーションコードを記述していますが、適用されているようです。 より高いレベルの別のコードの場合、コードはライブラリになります。 つまり アプリケーション/ライブラリ（フレームワークなど）コードへの分割は純粋な慣習であり、コンポーネントの再利用のレベルに依存します。 あなたはいつでも上に何かをねじ込むことができ、アプリケーションコードはそうではなくなります。 そして、これはすぐに、有効なものとそうでないものの選択が、使用するコードと使用しないコードによって既に決定されていることを意味します。
横にジャンプすると、誰が誰を使用するかを理解することさえできないことがあります。 つまり コンポーネントAはコンポーネントBとコンポーネントBコンポーネントA （^ 2）を使用できます。 つまり 何が起こるかを誰が決定するかは、まったく明らかではありません。
もつれ解き
この不名誉をすべて見ると、疑問がすぐに生じます。 どうする 多様性にinれないようにするために、自分が選択すべきガイドラインは何ですか？
これを行うには、他の場所でそのような問題がどのように解決されるかを見て理解することが役立ちます。 ただし、賢く見なければなりません。「スタンプ収集」と完全なソリューションを区別する必要があります。
切手収集とは何ですか？ これは集合的な用語です。つまり、目標とは何かを交換しました。 たとえば、私たちには目標がありました-愛する人と電話をしてコミュニケーションを取ることです。 そして、かつて、「ファッショナブル」と「美しい」ため、高価なおもちゃを買いました（^ 3）。 それはおなじみですか？ それはプログラマーには起こらないと思いますか？ 自分をflatめないでください。
エラー処理は目標ではありません。 エラー処理について話すたびに、すぐに停止します。 それは目標を達成する方法だからです。 そして最初の目標は、ソフトウェアを信頼性が高く、シンプルで理解しやすいものにすることです。 これらの目標を設定し、常に遵守する必要があります。 エラー処理はでたらめであり、議論する価値はありません。 私は例外をスローしたい-しかし、健康に！ 間違いを返した-よくやった！ 修道女が欲しい？ おめでとうございます、あなたは進歩の幻想を作成しましたが、それはあなた自身の頭でのみです（^ 4）。
それから私はそれを正しくする方法を書きたかったのですが、すでに書きました。 傷は治癒し、出血は止まりました。 要するに、ヒントは次のとおりです。
- 明確な境界を持つコンポーネントに分離します。
- 国境で、何がどのように飛ぶことができるかを説明します。 均一であることが望ましい。 しかし、はるかに重要です。
- それを使用するコードのエラーを簡単に処理できるようにします。
- ユーザーコードをロードせずに何かを内部で処理できる場合は、突き出さないでください。 ユーザーが処理する必要のあるエラーが少ないほど良い。
- ユーザーを尊重し、嫌がらせをしないでください！ 彼がコメントを読んで誓う必要がないように、予想される動作で直感的なインターフェイスを記述します。
5番目のアドバイスが最も重要です。 彼は最初の4つを結合します。
PS子供の頃、私はいつも蟻塚を見てみたいと思っていました。 数千匹のアリ、誰もが何かをし、彼のビジネスについてaboutう。 プロセスはオンです。 今、私も興味を持って見ています。 蟻塚の後ろにも。 何千人もの個人が小さなことをしているところ。 彼らのハードなビジネスで幸運を祈ります！
^ 1：人々はファッショナブルなものが好きです。 誰もが十分にプレイすると、C ++プログラマーが目を覚まし、その後すべてが向き直りました。
^ 2：これは、コンポーネントBにそれらを接続するいくつかの抽象化がある場合に発生する可能性があります。 制御の反転を参照してください。
^ 3：そして翌日、バム、画面がクラッシュしました。
^ 4：私はモナドに反対しているのではなく、吸引に反対しています。 エンドファンクターのモノイドのカテゴリーのモノイド！ 拍手と承認のうなずきが聞こえます。 そしてどこか遠く、かろうじて聞こえる、誰かがオルガスムを鳴らします。