例外に関するチームのガイドラインはありますか？[閉まっている]

私のチームは最近、一部の作業をオフロードする必要があった開発者の数が非常に少なくなったチームからプロジェクトを継承しました。私たちが継承したプロジェクトの1つは、ネストされたコードが散らばったプロジェクトとひどい例外処理です（例外は実際にはgotoステートメントとして処理され、通常のプログラムフローの一部として使用されていました）。

全体として、それは誰かが数年間咳をしてきた毛深いコードボールでした。

現在、私たちはかなり長い間いくつかのチームガイドラインを用意していますが、オブジェクトの構造、コーディングスタイル、およびそうでないものに関するすべての考慮事項があります。ただし、例外処理については取り上げていません。

だから、例外処理に関してあなたのチームにガイドラインがあるかどうか、そしてもしそうならどのようにそれらを実施するのか？

これらは、これまでに参加したどのチームの公式ガイドラインでもありませんが、例外は、本当に例外的な状況で、または絶対に（何らかの理由で）手を上げて発信者に通知する必要がある場合にのみ使用するべきだと思います（または現在のポイントからバブルアップし、潜在的にユーザーに至るまで）特定のコンポーネントが現在の状態で機能することは絶対に不可能であり、何らかの外部（他のモジュールまたはユーザー）の介入なしに回復することは不可能であることを知っている。

チームには、通常の例外を除いて、特定の例外処理ルールはありません。「通常の」動作に例外を使用しないでください。単に黙って例外を飲み込まないでください。

静的分析は、それらのいくつかを使用するのに役立ちます（使用する言語によって異なります）が、コードレビューの方が安全です。

現在のところ、明確なガイドラインはありません。主に、私のチームの誰もそれを間違っていないためです。（他の多くのトピックとは異なり、例外をいつどのように使用すべきかについての一般的な合意があります）

しかし、例外をgotoとして悪用されたのと同じ日に、間違いなく実装します。

例外は例外を再認識すべきだと思います。コードでワークフローとして例外を使用する場合、それは乱用され、オーバーヘッドが発生すると思います。したがって、それらを冗長に保ち、予期しないことが起こった場合にのみ使用してください。

注：接続データベースを関数に渡さないなど、最も一般的なmistackを回避するためのトレイ。しかし、primaryKeyが存在せず、何かを実行するために必要な場合に使用してください。

gotoのようなステートメントになるように例外を悪用する人々からコードを継承しなければならなかったことを残念に思います。

ユーザー入力または自分の制御を超える何かが発生する可能性がある場合（例：IOExceptions）、常にそれらをキャッチしようとしますが、コーディングエラー（例：NullPointerException）である可能性があるものはすべて、開発の初期段階でアサートでキャッチしようとするものです。

この種のコーディングによるパフォーマンスへの影響は、大きなマイナスです。恐ろしい開発者が理解できないほどの混乱に陥ったために会社が縮小していたのではないかと思います...