对于健壮性,错误就是信息。
如果可以概括一下好的代码的定义,简而言之,将如下所示。
“好的代码简短,简单且健壮-挑战在于弄清楚如何到达那里。”
前两个前提条件可以通过编写简洁漂亮的代码来满足。 通过不断的实践和毅力,我们可以逐渐掌握同样的知识。
第三个精美的“ Robust ”有点棘手。 除了精通代码外,我们在这里还需要谨慎行事。
谨慎使用例外; 代码可以将错误或异常事件传递给调用它的代码的特定方法。 简单来说,我们是在说:“ 嘿,我不知道该如何处理!! 希望其他人对此有所了解。”
而且,在大多数情况下,异常处理是介于“ 健壮性 ”和“ 正确性 ”之间的判断调用。 “ 正确性 ”表示永远不会返回不正确的结果,而“ 健壮性 ”则表示总是尝试做一些可以使软件即使在导致不正确结果的情况下也能继续运行的事情。
诀窍是在使用异常时取得适当的平衡。 明智地使用它们可以降低代码复杂度。 如果使用不谨慎,它们可能会对您的代码造成严重破坏,并使其无法遵循和维护。
以下是一些可以正确使用异常的方法。
首先考虑本地。 不要使用异常来推卸责任
在实现编程单元时,我们对调用者进行假设。 有时,这些假设随着时间的流逝而变得无效。 首先,我们也可能对调用者做出了错误的假设。
因此,我们不仅需要考虑如果这些假设是正确的,该怎么办,更重要的是,如果这些假设被打破,该怎么办。 这不仅可以帮助我们制作健壮的程序,而且可以使程序更可重用。
经验法则是,我们仅需要为真正例外的情况抛出异常。 例外是在处理意外情况与增加复杂性之间的权衡。 任何可以在本地处理的内容都应仅在本地处理。
包括所有导致它的信息
实现这一目标的不成文法则是“ 提早投掷,追赶稍后”。
当在程序单元中遇到错误状态时,我们必须在此时抛出异常,因为在这里您将获得有关错误的最精确信息以及发生异常的上下文。
无论是类,接口还是例程,必须从正确的抽象级别抛出异常,这一点很重要。 引发异常后,调用程序将捕获异常,并决定在引发异常时显示适当的错误消息。
这不仅对支持人员有利,而且可以帮助我们在更短的时间内找到根本原因。
将异常与正确的消息一起使用
异常的真正目的是以不被忽略的方式通知程序的其他部分。
为此,将其与正确的消息传递类型(无论是错误,警告还是信息)相关联非常重要。
错误消息提醒用户已经发生的问题。 相反,警告消息警告用户将来可能会引起问题的状况。 可以显示错误消息
典型的模式错误消息应执行以下操作。
·通知用户发生问题,解释问题发生的原因,并提供解决方案,以便用户可以解决问题。
·用户应该执行操作或由于错误消息而更改其行为。
典型的警告消息是模式对话框,就地消息,通知或气球,向用户警告将来可能会引起问题的状况。
警告的基本特征是它们可能会丢失以下一项或多项内容:
·有价值的资产,例如重要的财务或其他数据。
·系统访问或完整性。
·隐私或对机密信息的控制。
·用户的时间(相当长的时间,例如30秒或更长)。
写得好,有用的消息对于高质量的用户体验至关重要。 信息写得不好会导致产品满意度降低,并且是可避免的技术支持成本的主要原因。 不必要的错误消息会中断用户的流程,并导致代码繁琐。
规范您的例外。
需要使异常处理在整个应用程序中易于管理,为此,将它们标准化为一个通用框架非常重要。 标准化的异常处理框架不仅使应用程序易于维护和调试,而且使代码更简洁。 可以采用某些方法。
·根据需要创建项目特定的异常类。
·定义本地异常的情况
·定义全局异常的情况。
·确定是否需要使用中央异常报告。
·将日志聚合在一个位置,最好是一个数据库。
·使该数据库可从Web浏览器访问。
有了标准框架后,您将能够:
·在几秒钟内解决问题。
·使您的支持人员能够确定根本原因而不涉及您。
·防止测试人员针对同一错误创建多个票证。
·为您的业务省钱。
·保持周末和声誉不变。
最后,对于使用异常要非常谨慎
有时,对严重的运行时错误的最佳响应是仅释放所有获取的资源并中止程序。 让用户使用正确的输入重新运行程序。 确实不值得付出努力。
太多的例外会产生自己的问题。 如果您开始以各种可能的方式检查在每个可能的地方作为参数传递的数据,则您的程序将很繁琐且运行缓慢。 更糟糕的是,为创建异常而添加的其他代码增加了程序的复杂性。
正如Al Viro正确地说的那样。
诀窍是解决您遇到的问题,而不是要解决的问题。
关于作者-:
Ravi Rajan是位于印度孟买的全球IT计划经理。 他还是一位狂热的博客作者,Hai句诗作家,考古爱好者和历史狂人。 在 LinkedIn , Medium 和 Twitter 上与Ravi联系 。
From: https://hackernoon.com/how-to-make-your-code-robust-e96fe4d0aa33