ホットフォルダに配置されたファイルを継続的に処理するプログラムを書いています。
このプログラムは、管理者の介入なしに100％の稼働時間を実現する必要があります。言い換えれば、「愚かな」エラーで失敗するべきではありません。つまり、誰かが出力ディレクトリを削除し、それを再作成して次に進む必要があります。
私が考えているのは、プログラム全体をコーディングしてから、「エラーポイント」を探して、エラーを処理するためのコードを追加することです。
私が避けようとしているのは、誤ったまたは不要なエラー処理を追加したり、プログラムの制御フローにエラー処理を組み込んだりすることです（つまり、エラー処理がプログラムのフローを制御します）。おそらくそれはある程度流れを制御することができますが、それは悪い設計（主観的）を構成するでしょう。
「エラープルーフ」「クリティカル」プロセスの方法論は何ですか？
プロセスにエラーがなく、管理者の介入がない必要がある場合は、考えられるすべてのエラーを処理する必要があります。プログラムを停止する機会を残しておくと、それが起こり（マーフィーの法則）、わかりません。
考えられるすべてのエラーを処理する場合でも、プロセスが常に正常に実行されていることを確認するために、ログ記録と（メール？）アラート付きのモニターが必要になると思います。
最も重要なことは、単体テストの形式で仮定を文書化することです。各仮定に違反するテストを作成してから、プログラムが正常に回復するか、この状態を再び真にするためのアクションを実行することを証明する必要があります。
あなたの例を使用するには、誰かが重要なフォルダを削除する可能性がある場合、これをシミュレートするテストを行い、プログラムがクラッシュせずにこのケースを処理することを示します。
徹底的な分析の手法については、HAZOP調査があります。ここでは、プロセスの各部分について、そのプロセスのキーワードを検討します。プロセスプラントの化学物質の場合、これらは「より多くの」「より少ない」、「欠落している」、「より高温の」「より冷たい」「漏れ」「圧力」などである可能性があります。
HAZOPをソフトウェアに適用するときは、ソフトウェア内のオブジェクトに適したキーワードを検討します。
たとえば、ファイルを読み取る場合、「more」はバッファオーバーラン、「less」はデータの欠落、「missing」は存在しない、「leak」はファイルハンドルの欠如などと見なすことができます。