あなたは出荷しました、あなたはまれなセグメンテーションフォールトを受け取ります。ポインタをチェックするか、それを手放しますか？

出荷され、アサートがオフになっていると、コードでnullポインタ違反が発生したことを示すまれなクラッシュレポートが表示されます。開発環境では、問題はアサートによって検出されたはずです。

あなたが持っているのはクラッシュレポートだけなので、問題を再現することはほぼ不可能です。バックトレースを追跡しても、最初にクラッシュが発生した理由についての手がかりはありません。

オプション：-クラッシュを防ぐためにポインターチェックを追加します。これはクラッシュを防ぎますが、そもそもなぜそれが起こったのかさえわからないでしょう。-飛ばして、再現シナリオで再び起こることを願って

アプリケーションが誘導ミスルまたは自動ブレーキシステムを対象としていないとしましょう...

どちらを選びますか？

2番目の方法を選択しました。クラッシュが発生した時点でNULLポインタが予期されていなかった場合、クラッシュを非表示にしても意味がありません。ほとんどの場合、このNULLポインターは、他の何かが間違っているという症状の1つにすぎません。NULLポインターを使用して非表示にした場合、何かが壊れることはほぼ確実です。シナリオがランダムな場所で毎回クラッシュする点を知っていれば、シナリオをキャッチする可能性が高くなると思います。

1. クラッシュはどのくらいの頻度で発生しますか？それは、いくつかのあいまいなケースで多くの顧客に1人だけのために起こりますか？結果は何ですか（データ損失、システムクラッシュ）？100万回に1回の頻度で発生し、アプリケーションを再起動するだけでデータが失われない場合は、おそらく修正する必要はありません。そのままにしておきます。

2. アサートを追加してすべての顧客に出荷するのにどのくらいの費用（お金と時間）がかかりますか（顧客の一部だけが新しいバージョンを取得した場合、残りはチェックされていないnull問題に入る可能性があります）？問題を見つける可能性はどれくらいですか？エラーをキャッチすることを期待してコードにランダムチェックを入れるだけの場合、それは悪い習慣です...

3. 問題はお客様のマシンで再現できますか？そのマシンにアクセスできますか？これは本当に価値があるかもしれません

4. クラッシュレポートを確認し、提供された情報が有用であり、問​​題の診断に役立つことを確認してください

_{開発環境では、問題はアサートによって検出されたはずです。}

_{特定の順序では、それは捕捉および修正されたはずですが、現在のバックトレースは捕捉されていません。
クラッシュダンプの問題点を確認できるはずです。パラメータを確認したことがありますか？}

あなたがこれに入れたい時間の長さに基づいて行うことができる追加：

• クラッシュダンプをアーカイブし、クラッシュした行にコメントを付けてコードで参照し
  ます。これにより、非常によく似たクラッシュダンプを調べて、以前に発生したことを知ることができます...
  [費やした時間：短い]

• 追加のチェック、ロギング、... これを防止して、次回に詳細情報を取得したい。
  [費やした時間：中]

  コードでnullポインター違反が発生しました。

• この違反が発生するような方法でアプリケーションを呼び出すことが不可能であることを確認してください。
  [過ごした時間：長い]

最近では、assert（）をオンにして出荷しています。それはそれほどコストがかからず、敵意のある状況での生活をはるかに簡単にすることができます（つまり、顧客の環境は、多くの場合、開発またはQA環境よりも敵意があります）。