&“死程序不会说谎”在GUI程序

解答动态

• 

  引用书中的同一段话（我的重点）：
  尽快发现问题的好处之一是你可以更早崩溃，崩溃通常是你能做的最好的事情。另一种方法可能是继续，将损坏的数据写入某个重要的数据库，或者命令洗衣机进入第二十个连续的旋转周期。
  …当您的代码发现原本不可能的事情刚刚发生时，您的程序将不再可行。从这一点开始，它所做的任何事情都是可疑的，所以尽可能快地终止它。
  当程序员使用断言时，他们会说“这永远不会发生”。通常，在这些条件下终止程序是一种适当的反应，尤其是程序员的断言因为未知的原因被违背了。对于带有GUI的程序来说，这一点与对于控制台程序或服务来说是一样的。
  对于正常的异常，问题变得和以前一样：我们能从这个异常中有意义地恢复吗？这取决于；异常是在写入关键数据库的过程中发生的，还是用户只是给了我们一个不存在的文件名？我认为你问错了问题。很明显，这一原则尤其适用于GUI应用程序的上下文，我们最好问问它是否也适用于非GUI应用程序的上下文。为什么？因为对于GUI程序，通常有一个用户坐在系统前面，当崩溃发生时（用户看到您提到的“适当的错误消息”），他们可以立即采取一些明智的措施。根据应用程序的类型，此操作可能是
  重新启动程序并重试是否会再次发生故障
  如果可以避免此问题
  检查是否丢失了一些数据并启动恢复过程
  呼叫热线，或者给他们发一封电子邮件，告诉他们错误信息和所发生的情况使用不同的程序（或者可能根本没有软件），只要没有可用的bug修复2 或任何对给定系统最有意义的东西。
  对于非GUI应用程序，情况就稍微复杂一点。它们通常需要一些自动故障处理，因为系统是无人值守的。为了以可靠的方式实现这一点，通常使用多个进程，其中至少有一个不太复杂且以健壮的方式编写的进程具有或的角色，而其他进程具有工作者的角色。工作进程仍然可以遵循“崩溃早”原则。对于管制员来说，工人撞车是一种预期行为。因此，可以应用一些启发式方法来做出相应的反应（通常，它会自动执行上面列出的操作，这些操作是人类应用于崩溃的GUI程序的）。为了解决这个问题，除了worker controller之外，还有其他模型，但它们都使用多个进程。
  今天，甚至许多复杂的GUI应用程序（如web浏览器、字处理器或其他几十个程序）都是这样实现的：它们的某些部分在外部进程中运行。当这样一个进程“提前崩溃”时，通常不必关闭整个程序，只需终止进程，并直接在GUI中给用户一些我提到的选项就足够了。
  
• 

  简而言之，提前崩溃也是GUI的一种可取方法，但是导致这种情况的条件应该尽可能地减少。更详细地说，如果失去控制，系统会崩溃。一般来说，GUI的目标是让用户的生活更轻松，系统更容易理解。当崩溃时，它不再是图形化的，用户只会感到沮丧。因此，推广这种方法似乎有点奇怪。
  但是，当系统内存耗尽时，您是否尝试过GUI应用程序？或者当没有可用的windows资源时，因为句柄泄漏？一个窗口打开，拼命地通知您一个错误，但什么也没有出现，因为没有资源了。或者更糟：另一个窗口试图通知您错误窗口上的错误。不要谈论其他可能需要处理的非GUI事件。
  在这种情况下，早期崩溃是最好的选择。因此，Andy Hunt的实用程序员建议是一个很好的建议，同样适用于GUI.
  ，但是要使系统健壮，以避免事情变得如此糟糕，导致这种绝境和突然终止的情况应尽可能在无法预防和无法恢复的范围内错误：许多错误通常导致这种绝望局面的情况是可以避免的，例如通过清除输入、防止使用坏参数、验证OS或API函数是否可以在根据他们的行为继续之前，必须无误地完成成功。很多如果仔细考虑在哪一级可能出现什么问题，不利的情况是可以恢复的。这就是例外情况鼓励我们做的：例如，可能被零除是意外的，但它应该需要更多的崩溃系统。 因此，如果不立即考虑错误预防措施，就不能考虑您的具体问题。因此，请将这些建议与基本的防御性编程实践结合起来，例如在调用后验证参数和验证错误状态（WinAPI函数的调用频率是多少，只是忽略返回状态，导致两个声明后，一个不可恢复的，但完全可以预防的情况）。
  当它的任务关键 证明这是可行的？以期望具有高可靠性的软件为例：OS。上一年，你有多少次在微软Windows下出现BSOD或者在Mac上意外重启系统？与20年前相比，
  已经投入了大量资金，以首先防止不可控（质量保证+防御编程），并使这些系统强大，能够应对出现的情况（设计中的恢复策略、具有组件的体系结构，因此，在最坏的情况下，可以重新启动一个组件，而不是使整个系统崩溃）。。。在设计软件时，我用断言（和类似的“可疑防御”）填充代码，在部署时我将它们留在代码中。我的软件总是在寻找麻烦，因为“软件本身”实际上是唯一能够意识到某个错误并引起注意的一方。
  您的应用程序应该有一个“最外层”异常处理程序，它将“最后的异常”；您应该仔细地为这些异常制定出一个有意义的类层次结构——超越语言的内置部分。在捕获您希望在代码的特定部分中找到的异常时要特别注意，允许意外异常冒泡到更高级别的处理程序。找出一个策略来处理它们，即使其中一个是“我们现在别无选择，只能终止程序。”
  “异常”机制也可以用作某种转到。例如，当您意识到用户犯了错误时，您可能会深深地沉浸在代码中。您可以抛出适当类的异常，知道它最终将被所选处理程序捕获。您可以将参数附加到exception对象，我建议一个（dummy…）参数应该允许您唯一地标识代码中抛出它的点。这实际上是一个非常干净的方法来处理这些“特殊”的情况。
  “如果出了什么问题，一个的棒球会从某处飞向接球手的手套。因此，如果你没有看到这样的棒球，那就没有什么问题，因为每个人都在找麻烦，唯一要做的就是举手说“我不知道该做什么”，然后停止做你想做的事情。
  A GUI由不同的子系统组成，所有这些系统都应该在他们不知道如何处理的情况下做同样的事情——举起他们比喻的手，比喻地说“我不知道该怎么办”。最终，该消息要么会丢失，要么会到达进程中知道要做什么的部分。
  不管是GUI应用程序、命令行中的函数还是AWS函数。正如这句话所暗示的，其他任何事情都是谎言。被告知做某事时，系统要么报告“做了”，而事实上他们没有，要么就再也不说什么了。这两个都是谎言。
  过早崩溃，经常崩溃。
  
• 

  这要看情况而定。从理论上讲，一切皆有可能，终止整个过程
• End