最先进的错误和异常处理策略应该包括哪些内容?[闭门]

这里有这么多可能的答案,但我想试一下。

在设计错误和异常处理策略时,应用程序设计者应该考虑哪些问题?

1. 当您有多个开发人员时,应该很容易“钩住”您的错误处理框架,否则人们不会使用它。
3. 在处理异常时考虑临界性。例如,如果您有一个在线订购系统,并且该工作流的一部分是向网站所有者发送一封电子邮件,让他们知道已下了新订单。如果发送该电子邮件失败,用户是否应该收到错误并取消整个订单?

根据软件类型(COTS、内部业务应用程序、咨询软件、游戏、托管web应用程序、嵌入式应用程序等),策略将有何不同?软件类型重要吗?

1. 对于桌面类型或嵌入式应用程序,在调查错误报告时,记录有关环境的信息(操作系统版本、硬件、其他正在运行的应用程序等)非常有用。

道德、政治和法律问题?

在这里,我唯一能想到的就是桌面应用程序——“家庭电话”类型的应用程序通常是不受欢迎的,尤其是当它们提交有关用户机器的敏感信息时。

关于错误处理的各种观点(用户、开发人员、业务支持、管理)。

2. 从开发人员的角度来看,您需要尽可能多的信息来帮助诊断发生了什么-堆栈跟踪、环境信息等。

3. 来自业务支持和;从管理层的角度来看,他们希望知道如何处理错误(主要是在企业环境中)-谁负责应用程序(我应该调用谁/页面等?),以及关键性和任何可能的副作用(例如,如果此批处理作业失败,会影响哪些业务流程?)。书面文档是你在这里的朋友。

经验法则:

1. 编写代码以快速失败: Hunt & Thomas
2. 使用参数检查库测试所有参数-这些不是例外情况。它们是对(记录在案的)API的滥用。例子: google collections Predicates
3. 在特殊情况下使用例外:[Hunt&Thomas];提示34。异常不应用作返回代码。
4. 异常条件测试:异常是方法调用的后条件。如果您无法通过测试实现,则不应声明异常。
5. (对于Java)遵循 Josh Bloch's advice (第9章全部内容)。 5a。抛出适合于抽象的异常。 5b。争取失败的原子性。 5d。不要忽略例外情况。

我在工作中遇到了一些这样的问题,但实际上没有机会在那里探讨。我的想法:

在设计错误和异常处理策略时,应用程序设计者应该考虑哪些问题?

理想的异常处理策略是完全恢复并记录错误。第二十二条军规——如果你能做到这一点,你一开始不会把它写在代码中吗?因此,它本身并不是一个真正的“例外”,而且您的实现复杂性呈指数级增长。另一方面是自主系统和“自愈软件”方法。我认为最现实的策略是始终尝试并强制系统进入一致状态(即最小损坏)。您将总是被迫权衡一些事情—数据丢失或损坏、资源丢失导致性能降低等;但是,处于一致状态会增加您在容量减少的情况下保持运行的机会,而不是面临完全关闭。在项目团队中形成一致状态可能意味着建立自然默认值,将其用作重置状态。

根据软件类型(COTS、内部业务应用程序、咨询软件、游戏、托管web应用程序、嵌入式应用程序等),策略将有何不同?软件类型重要吗?

我认为每种类型的软件都有不同的审计和QoS要求,这反映在与停机和/或数据损坏相关的成本上;然而,总体战略是相同的。使用嵌入式系统,策略是尽量减少问题对用户的影响,并创建日志。您可以通过安静地重新启动软件(即重置状态)来实现这一点。使用托管的web应用程序,崩溃产生的会话数据可以转储以供以后分析,用户可以获得一个新会话。对于游戏(尤其是MMORPG),您需要投资维护快照数据,以防止玩家在服务器出现故障时失去进度。服务器集群和故障转移技术在这些实现中也非常重要。

透明度可能是错误和异常处理中最重要的部分,这将以维护审计的形式出现。这些问题的最终结果表明,系统故障(如果发生任何附带损害)是由设计人员无法合理预见的不可预测的事件链造成的。同样重要的是要证明,无论采用何种处理机制,都可以通过减少损害等方式产生积极的效果。在灾难性故障面前让用户保持在循环中也是很重要的(例如,“我的魔兽世界服务器去哪里了?”),但我的主要观点是,为了重建失败,应将透明度应用于纪律审计。

关于错误处理的各种观点(用户、开发人员、业务支持、管理)。

向开发团队获取尽可能多的关于正在发生的错误的信息是很重要的。如果没有用户体验错误情况,并且您可以确定有人正在检查日志文件,那么日志文件是很好的。自动电子邮件非常适合基于服务器的应用程序。警报消息是有问题的,因为用户从不阅读它们。一个对我有用的技巧是在显示用户友好的错误时将详细的错误跟踪复制到剪贴板上,然后训练用户将错误跟踪粘贴到电子邮件错误报告中。web等价物是显示友好消息,同时从服务器向开发团队发送电子邮件中的详细错误。

应该有一个最后的日志,换句话说,当写入日志文件导致错误时会发生什么?还应该有内置的防止“巫师学徒”类型问题的保护,在这些问题中,错误处理本身会将系统锁定。在桌面系统上,草率的错误处理代码可能会导致消息框层出不穷,除了杀死应用程序之外别无选择,可能会在过程中丢失数据。如果错误处理代码触发异常,可能会导致类似的问题。如果没有更好的选项,错误处理框架应该检测错误处理错误并停止报告错误。

对于重要的批处理过程,没有什么比主动通知成功更好的了。如果“批处理完成”电子邮件没有到达,即使错误处理是fubar,用户也知道发生了什么。

应在边界处捕获异常。所有事件处理程序、公共组件函数和服务方法都应捕获发生的所有异常。在某些情况下,重新抛出异常是有意义的;例如,当在web服务方法中捕获异常时,应该抛出SOAP异常。但是,允许Exception自动渗透到组件边界是个坏主意。

相反,在类的私有方法或嵌套在组件的复杂内部过程中间的方法中捕获异常通常是一个坏主意。除非可以从异常中恢复,否则在此上下文中处理异常是没有意义的。此内部代码必须结构化,以便在出现异常时释放所有资源并回滚数据库事务。每个方法中的Catch块都是混乱的标志,使用和最终使用的块都是健全的错误处理框架的标志。

每个组件边界可能需要不同的报告机制。对于设计为在不同上下文中运行的组件,提供一个错误处理接口,客户端代码可以使用该接口捕获错误消息。如果有人忘记挂接错误处理接口,请不要忘记最后的日志。

总而言之:

1. 获取详细的错误信息 为开发团队提供可靠的支持。

2. 陷阱错误始终位于组件边界 并且仅在组件边界处。

3. 确保所有代码异常安全。

4. 不要让错误处理框架 成为问题的一部分。

1. 从子组件中提取信息并将其映射到功能单元有助于我们的业务分析师和最终用户更好地理解错误

2. 根据您正在操作的域,分配业务优先级将有所帮助。

4. 系统级异常在不受干扰时更好。

6. 创建域驱动的错误策略:这意味着错误将对应于某些业务逻辑的失败。当然,大多数应该由开发人员处理,但是如果您在交易引擎等中处理不同企业之间的消息路由,可能会遇到某些场景

<opening my mind to new concepts>

• 或地震监测辊式打印机,检查一周的进度并将其与历史数据、使用数据进行比较,并将其与预设目标进行比较。临时将打印的长图表挂在墙上,并将项目团队召集起来进行审查。你买他们的饮料,同时解释你的问题,这一次非常具体,让程序员知道你到底需要什么策略。我跟你打赌,一杯咖啡能有效地、令人满意地回答你的问题。

<closing my mind to new contepts>