コンピューターの問題。私たちは皆、遅かれ早かれそれらを持っています。エラー、アサート、クラッシュなどの詳細を知ることは、当面の問題をより深く理解するために不可欠です。それについてすべて学びましょう。
アサートと は何ですか?
開発者がコードを書き始めると、すぐにその中に
if
ステートメントが導入されます。
if
ステートメントは、特定の条件をテストする必要がある場合に使用されます。たとえば、次のように疑似コードの
if
ステートメントを作成できます。
if (水位 > 高水位マーク) then {
raise_alert
}
言い換えれば、水位が最高マークを超えると、警報が発せられます。ただし、水センサーが壊れている可能性があるため、一致するようにコードを更新します。
if (sensor_readout == 無意味) then {
raise_error
失敗
}それ以外{
if (水位 > 高水位マーク) then {
raise_alert
}
}
素晴らしいですね。sensor_readout が無意味な場合はエラーが発生し、ルーチンが失敗します。そして、値が意味があることが判明した場合にのみ (
else
句により、つまり、逆の状況で何を行うか)、high_water_mark に対するwater_level のチェックに進みます。
ただし、誰かがセンサーの電源をオフにした可能性があります。しばらくはこのまま続けられそうです。考えられるすべてのシナリオをカバーできますが、それでもいくつかのシナリオが見逃されます。確かに、一致する
else
句で考えられるすべての状況をカバーし、各条件が別の条件と比較してチェックされることを検証することはできますが、そのような場合でも、変数のいくつかの組み合わせを見逃している可能性があります。
たとえ扱う変数のセットが限られていたとしても、ソフトウェア パッケージが考えられる組み合わせの数は非常に多くなります。さらに、この種の
if
条件付きテストは、ほとんどすべてのソフトウェアで非常に定期的に行われます。
このジレンマについてもう少し詳しく推論すると、私たち (開発者として) は (すべての人間が間違いを犯すのと同じように) 遅かれ早かれ、ソフトウェアを未定義の領域に突入させるコードを導入する可能性があることがすぐにわかります。変数 x は特定の値に設定され、変数 y は別の値に割り当てられますが、コードにはこれに対する規定がありませんでした。
これはまさに、アサーションがある程度は対応できる状況です。アサートは、特定の奇妙/珍しい/計画外/予期せぬ状況が存在するかどうかをアサートする別の条件であり、通常、未定義/未知の
if
で実行を続けるのではなく、プログラムを停止することによってそのような状況を処理します。 。
資産テストが投じる網は依然としてアサートを実装する開発者の賢さとスキルに限定されていますが、多くの場合、アサートは、さまざまな変数の状態をテストする
if
ステートメントの限られた範囲よりも広範囲に行うことができます。特定の危険な状況を回避するために非常に具体的に作成されています。
たとえば、小さな水センサーが雨タンクに取り付けられているとします。したがって、水は決して沸騰してはいけません。しかし、水センサーに温度計が付いていれば、たとえそのようなことが起こらない/起こらないはずであっても、それを確認することができます。上で開始した疑似コードにアサートを追加しましょう。
沸点 (摂氏 100 度) の代わりに、より妥当な最高摂氏 70 度を確認します。少なくとも私たちの意見では、雨水を捕捉することを考える場合、この温度は決して到達すべきではありません。 「意見」という言葉を覚えておいてください。これは、アサーションを実装する開発者の賢さを考慮するときに重要になります。 (これについては以下で詳しく説明します。)
if (sensor_readout == 無意味) then {
raise_error
失敗
}それ以外{
アサート (水温 < 70.0){
raise_assert_message
失敗
出口
}
if (水位 > 高水位マーク) then {
raise_alert
}
}
アサーションを逆に書きました。コードでは、水温が摂氏 70 度未満であることをアサートする必要があります。そうでない場合は、コード ブロックが実行され、アサート メッセージが生成され、ソフトウェアは失敗して終了します。
実際のコードのアサートは上記の例と非常によく似ています。これらは、特定の状況が当てはまるかどうかをテストし、その後、手元のプログラム/ソフトウェアを停止 (または制御された方法でクラッシュ) します。
多くの場合、これらの資産はアプリケーションのログ ファイルに記録されるか、画面出力に直接記録されることもあります。それらを確認したり、お気に入りの検索エンジンで正確なアサート メッセージのコピーを検索したりすると、多くの場合 (バグが以前に見つかった場合)、同じバグ レポートにたどり着きます。
Assert メッセージは多くの場合バグですが、単に開発者の推論のバグである可能性もあります。結局のところ、今から 1,000 年後の雨は摂氏 70 度を下回らないかもしれないと誰が言ったのでしょうか? （そうでないことを願いましょう！）
アサート メッセージは、開発者によってコードに導入されたアサートによってレンダリングされる出力です。つまり、ソフトウェアによって生成され、画面またはログに表示される実際のテキスト出力です。たとえば、上記のプログラムに対してこのアサート メッセージが表示されていると想像してください。
アサート: (water_temp < 70): (88 < 70): false
(一部のアサート メッセージのように) 少し不可解に見えますが、もう少し詳しく見ると、2 番目の部分で、
water_temp
が 88 によって交換され、出力が
false
あることがわかります (つまり、水のアサート Water_temp < 70 が失敗しました)。角度は 88 度だったので、アサートによってアサート メッセージがトリガーされました)。はい、少し混乱するかもしれません。
これらの新しいスキルを身につけると、次にアサート メッセージを見たときにそのメッセージをデバッグすることがはるかに簡単になります。また、アプリケーションの停止時に何が問題だったのかを正確に理解するのが容易になる場合もあります。
エラーと は何ですか?
コンピューティングにおけるエラーは、さまざまな理由で常に発生します。これらは開発者レベルとユーザー レベルの両方で、またその間のあらゆる段階で発生します。たとえば、DevOps エンジニアが必要なファイルを含めるのを忘れたり、パッケージ署名者がソフトウェアに署名するために間違ったキーを使用したりする可能性があります。
つまり、コンピューター エラーは、コンピューターのハードウェアまたはソフトウェアの問題として定義できます。上記の限定された疑似コードでもエラーの例がいくつかあります。
sensor_readout == nonsensical
条件が満たされると、エラー メッセージが表示されます。
他のエラーよりも一般的な特定のエラーがあります。たとえば、間違ったパスやファイル名を使用することはよくあるエラーです。電源関連の問題 (バッテリー残量低下など) も非常に一般的なエラーです。
エラーはアサート メッセージとはまったく別のものであり、アサート メッセージ自体はエラーとして、またはむしろアサートによってカバーされる未定義の状況として見なすことができます。一般に、コンピューターのエラーは、「これを修正するには人間が必要だ」という意味でよく解釈されます。
コンピュータがよりインテリジェントになり、AI が進化するにつれて、発生するエラーが少なくなることが期待されますが、この分野では議論の余地が多く残されています。
クラッシュと は何ですか?
コンピュータのクラッシュにはさまざまな形があります。私たちは皆、Microsoft Windows のブルー スクリーンについてよく知っています。これは、アプリケーションが誤動作したり、オペレーティング システムやマシンのハードウェアのコア部分に障害が発生したりしたときに発生する傾向があります。
ただし、ほとんどの場合、クラッシュはソフトウェア アプリケーションが未定義の状況に陥ったことです。このような未定義のシナリオが多数考えられます。コンピュータは、すでに使用されている RAM 領域に書き込もうとしたために、コンピュータ自体または別のアプリケーションが混乱した可能性があります。あるいは、ゼロで除算しようとした (これは不可能です)、または同様の状況に遭遇した可能性があります。
多くのオペレーティング システムでは、コア ダンプ ファイル (そのように構成されている場合) が書き込まれます。これにより、開発者や、場合によってはある程度のスキルのあるエンド ユーザーが、当面の問題をデバッグできるようになります。
コア ダンプ ファイルの分析など、問題が発生した場合のデバッグについて詳しく知りたい場合は、 「GDB を使用したデバッグ: 入門」の 記事が興味深いでしょう。
クラッシュは、アプリケーションが未定義の状況に陥った結果として発生することもあります。この状況は、エラー (アプリケーションが何か問題があることを通知する最も簡単な方法) やアサート (より深い問題で、当初はシステムによって除外されていました) によって処理されません。開発者は不可能ですが、依然として発生しています)。
また、テスト用にビルドされたプログラム、つまり、最終結果のバイナリにデバッグ情報 (デバッグ レベルのみのアサートを含む) が埋め込まれているプログラムは、たとえば次の場合のように、アサートを生成するときにクラッシュする可能性があることに注意してください。 、MySQL サーバーを使用します。
まとめ
この記事では、アサーション、エラー、クラッシュの概念とそれらの関係について説明しました。私たちは、コード内でアサートがどのように見えるか、そしてこれが水センサーで水位と温度を監視する実際の例にどのように関連しているかを詳しく調べました。次回アサーション メッセージに遭遇したら、よく見てデバッグを楽しんでください。
