例外処理コードの記述をいつ開始しますか？いつログ文を書き始めますか。
この質問を詳しく説明するために、log4netロギングを備えた.NETプラットフォームを使用していると仮定しますが、一般的な方法で自由に回答してください。
解決策：Windowsフォームプロジェクト。プロジェクト：UI、BusinessRules、DataHandlers
だから、作成、読み取り、更新、削除などのデータ操作を最初に行うDataHandlersを書くことに取り掛かりますか？
次に、ビジネスルールでフォローアップします
そして、UIまたは上記の他の組み合わせ。
アプリケーションの機能をテストします。
そして、例外処理コードの作成を開始し、最後にロギングコードを作成しますか？
例外処理コードの記述を開始する適切なタイミングはいつですか？
PS：本Clean Codeの中で、彼らは最初にtry-catch-finallyブロックを書くと言っています。それで、この質問をすることになりました。
回答:
例外を引き起こす可能性のあるものを呼び出すものを書いているときに、例外処理コードを書きます。
たとえば、ネットワークにデータを送信するものを作成する場合、接続タイムアウトを処理するコードも作成する必要があります。例外はあなたがしていることに直接関係していて、その仕事はあなたの心に新鮮です。
一方、不正な形式のプロトコルデータユニットに遭遇したときに例外を発生させるパーサーを記述している場合、パーサーが生成する例外の例外処理コードを記述することはできません。（もちろん、パーサーが例外を発生させる方法とタイミングと理由を示すテストを作成しています！）
あなたの書くための提案の背後にある理由のtry-catch-ついに最初は2倍です：最後にリソースをクリーンアップするための機能は/消費を作成し、書いているキャッチして、関数を使用している呼び出しが失敗する場合が素敵なリマインダーですそして、それらの障害を（必要に応じて）処理する必要があります。
事後にログを追加する傾向があります。それが賢明かどうかはわかりませんが、それは私にとってうまくいったことです。受け入れテストなどの実行を開始し、問題にヒットし始めると、エラーを追跡できるようにログを追加します。（そして、ログインしたままにします。）
私の経験では、最初から適切なエラー処理とロギングを使用してコードを記述しないと、時間的な制約のために実行されません。私がこれまでで最も成功した開発努力は、コーディング標準、エラーの処理方法、ロギング、基本アーキテクチャ、テストツールなど、基本的なアプリケーション構造の決定に費やした時間から始まりました。
それ以外の場合は、「エラー処理の改善」や「ログシステムの作成」などのバージョン2.0のタスクがあることがわかります。これらは新機能を優先してカットされ、「やることが多すぎる」ため、考えていなかったエラーケースのすべてのバグを修正します。（ロギングシステムがないため、これには永遠に時間がかかります。
あなたが何をしているかに依存します
例外の場合：
エラーが発生する可能性のあるもの、または例外が発生してそれらを書き込むようにするための優れたトップレベルポイントがあるものを書く場合。
パフォーマンスを必要とし、エラーの可能性が低いものを作成している場合、エラーハンドラーを置く意味のある場所が不足しているため、テストでエラーハンドラーが必要であることが証明されます。
どちらの場合でも、エラーを処理するのに便利なものがない場合は、バブルを発生させることを検討してください（ハンドラーなし）
ロギング用：
監査証跡が必要な場合は、最初にログを作成する必要があります。エラーを一番上までバブルさせる場合は、ログをキャプチャできるように、ログも提供する必要があります。
これらのケースとは別に、私は通常、テスト/使用が必要であることが証明された場所にのみロギングを追加し、通常はそれが完了したらオフに設定するオプションを作成します。
監査と例外処理をサービスとして実装できます。アプリケーションレベルの監査ログには、各ビジネストランザクションに関するステータスデータが必要です。ビジネスまたはトランザクションコンテキストでアプリケーションを監視するには、サービス内の監視インターフェイスが、サービス呼び出しに固有のトランザクションのステータスを詳述するメッセージを送信する必要があります。これには、各サービスがビジネストランザクションの重要なステップでステータスメッセージを送信する必要があります。その後、リアルタイムメッセージを作成して、ステータスメッセージ（トランザクションIDなどのメッセージのセマンティクスに基づいて）を複合アプリケーション内のサービスと関連付けることができます。これにより、SLA管理、障害追跡、および問題判別のためのビジネストランザクションのエンドツーエンドビューが提供されます。
監査サービスは、構成で定義された基準に基づいてメッセージを消費および記録できる状態マシンとして実装できます。汎用の例外ハンドラーは、監査サービスを使用して、エンタープライズSOAで発生する問題の集中ビューをサポートし、例外ベースの監視をサポートすることもできます。ソリューションで発生してはならない条件は、例外ハンドラーに例外メッセージを送信するように装備されています。