假设您有一个业务对象,其当前状态意味着您的代码中存在某种错误。或者基本上是您使用自己的数据但处于永远不会违反某些规则的状态的任何情况。我喜欢通常检查这些条件和假设,因为它允许我在接近其来源的早期捕获错误。但是,如果这样的逻辑检查失败,最佳做法是什么?
我知道Debug.Assert语句非常方便,但是我不是很喜欢它们,因为它们只出现在调试模式下,而不是在测试或发布阶段,显然仍然包含很多这样的错误。我宁愿被告知这个检查失败了,而不是尝试调试代码中发生的问题。我的解决方案看起来像抛出某种异常。这是个好主意吗?
答案 0 :(得分:1)
你是对的,抛出异常。
您可以扩展Exception类并在这些情况下使用扩展版本,这样您就可以在链中进一步处理它们,以便在必要时记录和暂停应用程序。
try
{
}
catch(MyException ex)
{
ex.LogError();
if(ex.IsCritical)
throw ex;
}
答案 1 :(得分:0)
是的,在我看来,这是正确的做法。这个例外会冒出来,不会被忽视,让你回到问题的根源。
答案 2 :(得分:0)
我通常检查业务对象本身中的此类问题,并抛出异常,忽略会导致对象具有无效状态。此类例外包括(但不限于):
IllegalArgumentException
传递的参数是不可接受的(例如,在不允许的情况下为null)IllegalStateException
表示对象可能被驱动到不正确的状态(与参数无效的情况不同)因此,业务对象本身永远无效。
我立即检查这些情况。我迫切希望避免的情况是修改一个对象,使其处于无效状态,并且稍后才会发现(可能在几年之后 - 想象将这样一个对象序列化并在一年之后对其进行反序列化)。这将使发现这些问题的根源几乎不可能。
我当然希望在生产和开发/测试阶段进行这些检查。通常,与正常操作所花费的时间相比,执行此类检查的成本可以忽略不计,特别是与您从这种情况中恢复所需的时间相比。