90年代半ば、DOSでのプログラミングからWindowsに切り替えたときに、私の指導者が例外メカニズムを紹介してくれました。
それ以来、意見が根付いてきました。例外でクラッシュするプログラムは悪いプログラムです。 緊急事態が発生した場合は、すべての例外を処理し、アプリケーションを終了する必要があります。
これは、通常のWindowsアプリケーションにも当てはまります。 実際、アプリケーションがクラッシュした場合、ユーザーは不明瞭なエラーメッセージを受け取り、その結果、不安定なアプリケーションに対する否定的な認識を受け取ります。
自動例外処理ツール（EurekaLogやその類似物など）について学んだ後、私の意見は変わり始めました。
そして、Google Playのレポートシステムとの会議後に最終的に変更されました。
この投稿は、コードにラッシュチェックを押し込むことを教えてくれる数千の例に対する魂の叫びです。
この記事を書いた理由は、NDKとJavaコードの相互作用の実装に関するアドバイスを求めた友人との対話でした。 このマニュアルに基づいて書かれたソースコードを見せられました。
質問コード：
jmethodID method = env->GetStaticMethodID(interfaceClass, "callBack", "(Ljava/lang/String;)V"); if(!method) { LOGE("callback_handler: failed to get method ID"); return; } env->CallStaticVoidMethod(interfaceClass, method, js);
これは見た目は良いが、実際には新しい問題を作成するだけの古典的なコード例です。
ここで確認する必要があるのは1つの場合のみです。callBackメソッドが存在する必要はなく、通常のアプリケーションモードでは存在しない場合があります。
ネットワークモジュールの結果を確認するとき、または外部ファイルなどを操作するときは、確認が必要です。
つまり、外部要因によりエラーが発生する可能性がある場合です。 この場合、エラーのチェックは私たちの直接の責任です。
コードによってエラーが生成されると状況は完全に変わり、外部要因に依存しません。
callBackが当社によって記述されており、コードに存在する必要がある場合、検証は必要ありません。
チェックはエラーのみを偽装します。
マスキングエラーが悪いことを理解することは非常に重要です。 例外を除いてアプリケーションをドロップするよりもはるかに悪い。
メッセージはログに記録され、テスト中にポップアップすると言うことができます。
まあ、それがポップアップする場合は素晴らしい。 そして、それが現れない場合は？ ユーザーがアイドルコードを離れた場合、誰がcallBack呼び出しを静かに無視しますか？
ユーザーは、意図した機能を満たさないプログラムで作業します。 さて、これがアプリケーションに深刻な影響を与えない些細なことであれば。 しかし、コードの重要な部分がそこに隠れていて、そのためにユーザーの作業のすべての結果が間違っていることが判明した場合はどうでしょうか？
チェックを削除すると、callBack呼び出しに遭遇した最初のユーザーがアプリケーションのクラッシュを受け取ります。 そして、あなた-いっぱいになった呼び出しスタックを持つエラーレポート。 これにより、少なくとも問題に注意が向けられます。 はい、ユーザーは不満に思うでしょう。 ただし、5時間以内に新しいバージョンをGoogle Playにアップロードすると、何千人ものユーザーがこの問題を知ることさえありません。
これは、時限爆弾アプリケーションで動作する巨大なクライアントベースよりもはるかに優れています。
エラーチェックは、アプリケーションの重要な部分です。 あらゆる種類のエラーが常に発生します。 いくつかのエラーが発生しなかった複雑なアプリケーションを一度も起動することはありません。 ただし、標準エラーと標準エラーを区別する必要があります。 通常のエラーとは、許容され、その影響が予測可能なエラーです。 これらのエラーはアプリケーション内で処理する必要があり、作業のロジックは状況に応じて変更する必要があります。 いかなる場合でも、異常なエラーは標準チェックで処理されるべきではありません。 NULLチェックがある場合、コードブロックをつかんで押し込むことはできません。 オブジェクトがNULLになった理由と、アプリケーションで脅威になるものを常に明確に理解する必要があります。
それでは、小切手をどうするか？
何もできません。 チェックを外すだけです。 上記の例では、メソッドがない場合、次のステップで例外が発生することが確実にわかっています。
このオプションは受け入れられますが、あまり良いものではありません。例外のスローはコードの範囲外であり、例外が発生することを保証できないためです。
したがって、理想的なケースでは、ログへのエラーの書き込みではなく、コードの実行を停止してエラーレポートを送信することを保証する例外を発生させるチェックが必要です。
もちろん、私は自分の経験から、エラーの偽装がどれほど有害かを知っている専門家にアメリカを開放しませんでした。
このテキストは、インターネットのサンプルを使用してプログラミングを学習する初心者を対象としています...しかし、サンプルには、無意味で無慈悲なチェックがたくさんあります...