.NET, Software Design, 存档
     

通宵软件设计提示: 提示 #2

对于《四夜的软件设计提示》的第二部分, 我想谈一些关于异常的问题。. net 中的异常提供了处理错误的绝佳方法。我们都知道不要使用异常来控制流, 但还有许多其他方法可以滥用异常。

滥用异常可以是任何东西, 从引发基本异常类, 到抛出的不仅仅是异常。但最常见的滥用异常处理的方法是简单地压制它们。我们都看到了一些应用程序, 它们执行类似于以下操作:

某业务对象 bo = SomeBusinessObject.LoadWithId(4);
尝试 {
    博。值 = int。分析 (txt text领域. text);
} 捕获 {
   值不是 int..。所以忽略它。
}
博。保存 ();

抑制异常的问题在于, 大多数组件并不只是为了好玩而抛出异常, 因此首先引发异常的一些根本原因。

上面的例子看起来足够无辜。int32 的 parse 方法如果无法解析输入字符串, 则会引发异常。但是, 如果将来另一个开发人员认为业务对象的 "某种价值" 需要某种限制可接受值的业务规则, 该怎么办?

公共类某些业务对象 {
    其他类代码

    公共 int 某些值 {
         获取 {返回 _ 某个值;}
         集 {
             如果 (值< 0)></ 0)>
                  引发新的业务规则异常 ("某些值的无效值");
             _ 值 = 值;
         }
    }
}

在这种情况下, 业务对象正在强制实施业务规则, 以防止设置负数。现在发生的情况是, 如果违反了业务规则, 我们第一个示例中的代码将以静默方式失败。在这种情况下, 解决方案是改为检查输入值是否有效到 int32, 然后检查业务规则的有效性。或者简单地说, 不要压制异常。你永远不知道你最初的假设什么时候会改变。

About Jason

Jason 是一位经验丰富的企业家和软件开发商, 在石油和能源行业有丰富的工作经验。精通领导力、移动开发、数据同步和 saas 架构。强大的工程专业, 阿肯色州立大学计算机科学学士学位。
View all posts by Jason →

发表评论

电子邮件地址不会被公开。 必填项已用*标注