.NET：再论异常处理，一个真实的故事

背景

关于是使用枚举或布尔类型来表示方法执行状态，还是使用异常，可以参考这里的文章：http://www.google.ee/search?q=site%3Awww.cnblogs.com%2Fhappyframework%2F%20%E5%BC%82%E5%B8%B8。

今天贴出一个真实的场景（一个朋友重构之前和之后的代码）供大家参考。

一个朋友的示例

重构前

重构后

示例分析

重构前

使用枚举或布尔类型来表示方法执行状态，导致程序中出现了大量的if(xxx){ //异常流程处理 }，这部分代码会充斥到所有地方，程序中包括了对异常路径的处理，随着调用栈的深度增加，编程更不爽，如：需要在下层的枚举状态之上再扩展自己的枚举状态。

重构后

用异常代表方法执行失败的状态，在边界类（控制器）中采用AOP的方式拦截异常并自动输出友好的Action Result给浏览器，程序中只有正常的代码，看起来非常清晰。

有朋友会问：如果某些异常需要个性化处理咋办？，答：扩展你的AOP逻辑。更简单的做法是使用自定义异常 + catch就行了，没有被catch的异常还是会被拦截。

备注

关于什么情况使用异常？什么情况使用返回结果？只有一条原则：不要用异常处理正常的业务逻辑。

一个示例

你希望获取验证信息，然后对此做进一步的处理（包装成UI友好的信息），这时用异常明显不合理。而如果出现了验证失败，程序要立即结束，对于刚才包装好的验证信息，可以采用异常的形式返回给UI，代码如下：

var validationResult = entity.Validate()
if(!validationResult.IsValid())
{
   throw new InvalidationException(CreateMessage(validationResult));
}