什么时候该用异常,一直都让我疑惑,看了《C#技术揭秘》后,有一点给我留下了深刻的印象:
异常处理较返回错误编码,具有减少代码量,降低代码维护成本的优点(当然,可能存在性能方面的问题,这不在讨论之列)。
关于这点,作者给出了丰富的代码,做出了有力的证明。但是一直困扰我的异常的使用方法却没有给出正面回答。作者大都在讨论如何去捕获异常,而何时抛出异常却讨论得不多。
但是在阅读通过异常返回错误与通过错误编码返回错误的比较时,我发现了一个有趣的东西,这两者实际上都是在讨论如何去控制程序的执行流程。
异常处理对于流程的控制,就像抛出与捕获一样分为两个方面:
- 如果错误(或某种情况)发生,是否允许程序的控制流继续执行下去(异常的抛出)
- 如果当前有异常发生,当前的代码是否有机会让程序的控制流进入到一个合理的状态(异常的捕获)
我认为可以用以上两条,作为判断异常处理的准绳。其实大家现在应该可以发现,这个所谓的准绳的着重点在于异常对于流程的影响,而不再是在什么情况下才使用异常。
对于流程控制,最直接的莫过于下面这段代码
try { foreach (var lockGroup in lockGroups) { ... foreach (var newlock in lockGroup.ToArray()) { ... if (diningBlocks.Exists(n => testLockRange.IsOverlapped(n.StartTime, n.EndTime))) { status = LockStatus.InResourceBlock; throw new LockException(); } var diningAvail = availabilities.Find(n => n.Time == newlock.StartTime.TimeOfDay); if (diningAvail == null) { status = LockStatus.Failed; throw new LockException(); } ... if (newLockQuantity > diningAvail.MaxAvail && !canOverrideLock.AllowOverBook) { status = LockStatus.Override; throw new LockException(); } else if (newLockQuantity + reservedQuantity + currentLockedAvail > diningAvail.MaxAvail && !canOverrideLock.AllowOverBook) { status = LockStatus.Override; throw new LockException(); } ... } } } catch (LockException) { return new DiningLock[] { }; }在上面的代码中,有两层for循环,当最内层出现某种情况时,要求停止整个for循环的执行,显然用两个break是不行的,还得加入一个辅助变量。
但是,如果用异常,这个处理就简单多了。可以直接在最内层的抛出异常,在最外层(或是流程控制需要的地方)捕获异常。
在上面的代码中,异常处理起到了流程控制的作用,而不仅仅传递错误信息,对代码的简化做出了贡献。