您何时开始编写异常处理代码？您何时开始编写日志记录语句。
出于阐述这个问题的目的，让我们假设我们使用Log4net日志记录在.NET平台上，但是可以以一般方式随意回答。
解决方案：Windows窗体项目。项目：UI，BusinessRules，DataHandlers
因此，您是否打算编写DataHandlers来进行数据处理，例如首先创建，读取，更新，删除。
然后遵循您的业务规则
然后是您的用户界面或以上的任何其他排列。
测试您的应用程序的功能。
而再开始写你的异常处理代码和最后日志记录代码？
在什么时候开始编写您的异常处理代码？
PS：在书Clean Code中，他们说首先写您try-catch-finally块。那促使我提出这个问题。
Answers:
在编写调用可能导致异常的内容的代码时，您要编写异常处理代码。
例如，当您编写将数据发送到网络的内容时，还应该编写处理连接超时的代码。异常与您正在做的事情直接相关，因此工作是新鲜的。
另一方面，如果编写的解析器在遇到格式错误的协议数据单元时引发异常，则无法为解析器产生的异常编写异常处理代码。（但是，当然，您正在编写测试以显示解析器如何以及何时以及为何引发异常！）
建议首先最终编写try-catch的原因有两个：最后是清理函数创建/使用的资源，写catch很好地提醒了您正在调用的函数可能会失败，并且您需要处理（如果需要）这些失败。
我倾向于在事实之后添加日志记录。我不确定这是否明智，但这正是对我有用的。当我开始运行验收测试之类的东西，并开始解决问题时，然后添加日志记录以便跟踪错误。（然后我退出登录。）
取决于你在做什么
例外情况：
如果您正在编写可能有错误的东西，或者在顶层有很好的提示的地方要让异常冒出来，以便随时进行编写。
如果编写的东西需要性能，并且出错的可能性很小，那么缺少放置错误处理程序的有意义的地方，可以在测试证明您需要它们的地方编写错误处理程序。
无论哪种情况，如果您对错误没有任何帮助，请考虑使其冒泡（无处理程序）
用于记录：
如果需要审核跟踪，则应首先编写日志记录。如果您让错误一直冒泡到顶部，则还需要在此处提供一些日志记录，以便可以捕获日志。
除了这些情况外，我通常只在测试/使用证明有必要的地方添加日志记录，完成后通常会选择将其关闭。
您可以将审核和异常处理作为服务实施。应用程序级审核日志记录需要有关每个业务交易的状态数据。监视业务或交易环境中的应用程序的能力要求服务内的监视接口发送详细说明特定于服务调用的交易状态的消息。这要求每个服务在业务交易中的关键步骤发送状态消息。然后，您可以构建一个实时查看器，以将状态消息（基于消息的语义-例如事务ID）与复合应用程序中的服务相关联。这提供了用于SLA管理，故障跟踪和问题确定的业务交易的端到端视图。
然后，可以将审核服务实现为状态机，该状态机可以根据其配置中定义的标准来使用和记录消息。通用异常处理程序还可以使用审核服务来支持集中查看企业SOA中发生的问题-支持基于异常的监视。解决方案中的任何不应该发生的条件都会被检测为向异常处理程序发送异常消息。