最先进的错误和异常处理策略中应该包括什么?[关闭]

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

1. 当你有多个开发人员时,应该很容易“钩住”你的错误处理框架,否则人们就不会使用它。
2. 明智地使用事务来保持数据一致性。我经常看到应用程序在流程中途发生故障,导致数据不一致,因为整个操作没有正确回滚。
3. 在处理异常时考虑关键性。例如,如果您有一个在线订购系统,并且该工作流程的一部分是向网站所有者发送一封电子邮件,让他们知道已经下了新订单。如果发送电子邮件失败,用户是否应该收到错误并取消整个订单?

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

1. 对于桌面型或嵌入式应用程序,在调查错误报告时,记录有关环境(操作系统版本、硬件、运行的其他应用程序等)的信息可能非常有用。
2. 对于企业应用程序和web应用程序,电子邮件错误通知、短信和与ECO工具(如Tivoli)的集成等功能变得非常有用。

伦理、政治和法律问题?

我在这里唯一能想到的是桌面应用程序——“电话回家”类型的应用程序通常不受欢迎,特别是如果它们提交了可能敏感的用户机器信息。

1. 从用户的角度来看,尽量通过设计界面使其难以出错来避免错误。不要问用户可能无法回答的问题(中止、重试、失败?)

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

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

我来自Java背景,但我的回答应该适用于。网,也是。

经验法则:

1. Hunt & Thomas ;提示33
2. 使用参数检查库测试所有参数-这些不是例外情况。它们是对API(已记录)的滥用。例子: google collections Predicates
3. 在特殊情况下使用例外:[Hunt&Thomas];提示34。例外情况不应用作返回代码。
5. (适用于Java)关注 Josh Bloch's advice (第9章全部)。 一些重要提示: 5a。抛出适合抽象的异常。 5b。努力实现故障原子性。 5c。在详细信息中包含故障捕获信息(或将其封装在异常本身中)。 5d。不要忽视例外情况。

我在工作中遇到了一些这样的问题,但并没有真正有机会在那里探索它。我的想法:

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

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

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

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

伦理、政治和法律问题?

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

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

作为用户,错误处理应该是完全不可见的。如果服务器崩溃,我仍然希望我的银行交易按计划完成,而无需致电银行并重新运行交易。

作为开发人员,错误处理是应用程序设计中最困难的部分。由于人员和技术因素而可能出错的事情的数量,以及如何将它们分类为我们可以编写代码来处理的情况,都是非常困难的。我们依靠项目预算和管理来指导这些决策,但最终,这仍然像玩俄罗斯轮盘赌游戏。

用于业务支持和;管理方面,我认为错误处理就像在软件开发阶段支付的保险一样,可以减少因软件故障而遇到不便或中断的客户需要赔偿的情况。这也是软件质量和问责制的衡量标准(即他们想知道哪个部门/小组/开发人员负责)。

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

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

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

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

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

请记住,异常是例外的(如果你期待它们,它们就不会被称为异常!)与其试图预测何时可能发生错误,不如专注于支撑你的组件边界。即使是不可能出现错误的琐碎代码,如果它位于边界上,也应该有一个catch块。这样,当以后以意想不到的方式修改代码时,架构仍然成立。

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

综上所述:

1. 获取详细的错误信息 对开发团队来说是可靠的。

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

3. 使所有代码异常安全。

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

我不打算赢得赏金,但以下是我使用过并受到好评的一些策略:

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

3. 一个单独的错误查看器应用程序帮助我们在报告错误之前查看错误,以便我的团队可以开始修复它们。

4. 当系统级异常没有被弄乱时,它们会更好。

5. 异步记录错误将对整体策略和设计有很大帮助。

6. 创建域驱动的错误策略:指与某些业务逻辑失败相对应的错误。当然,大多数都应该由开发人员处理,但如果你在交易引擎等中处理不同企业之间的消息路由,你可能会遇到某些情况

<opening my mind to new concepts>

• 通过模拟纸带绘制发生的错误流程图 或地震监测辊式打印机,检查一周的进度,并将其与历史数据、使用数据进行比较,并与预设目标进行比较。临时将打印好的长图挂在墙上,并召集编程团队进行审查。你买他们的饮料,同时解释你的问题,这次非常具体,这样程序员就知道你到底需要什么策略。我敢打赌,一杯棺材就能有效地、令人满意地回答你的问题。

<closing my mind to new contepts>