DIY博客园

为什么要这样做？我估计是大家被BUG吓怕了，生怕生产环境出现各种莫名其妙的错误，比如最经典的NullReferenceException,可问题是你用Try…Catch包裹起来后错误是不会爆出来了，但是执行结果是你想要的么？恐怕bug还在那里，只是经过你的Try…Catch之后，bug更加难找了，原本你用vs调试起来，直接就断在了异常发生的地方，现在呢？你得一步步跟踪过去。

　　这不是最主要的问题，最重要的问题是你在开发过程中隐藏了bug,如果当时你没加这个Try…Catch,恐怕你早就发现这个bug了，因为程序压根就跑不下去。

　　异常信息应该由最上层的框架捕获，比如MVC中有ExceptionFilter,你可以在这里记录详细日志，别把黄页抛给用户就可以了。我想写一个Try…Catch的场景，但是居然一下子想不出来一个很好的场景，因为真真需要写Try…Catch的场景是很少的，你一旦想写Try…Catch，首先想想你是不是在故意隐瞒Bug.

　　反而我鼓励大家写Throw exception,比如这种场景:

public void Register(string userName,string password) {     if(string.IsNullOrEmpty(userName))         throw new InvalidDataException("user name can not be empty");     if(string.IsNullOrEmpty(password))         throw new InvalidDataException("password can not be empty");     //.... }  public void Register(string userName,string password) {     try     {         //....     }     catch (Exception)     {     } }

　　理论上，虽然UI做了各种校验，我们写的Register任然保持对参数的不信任，继续抛异常而不是Try..Catch,这样你是不是能提前发现UI没有校验的bug呢？

　　追加内容：很多同学对此文的结论难以接受，最有疑问的就是“Try…catch可以记录日志，捕获异常的详细信息，不会让程序挂掉”, 我需要重申的是:Try…Catch的作用不是用来记录日志的，任何框架都在顶层提供了捕捉异常的方案：

　　以.NET为例：

　　1. Winform,可以:

AppDomain.CurrentDomain.UnhandledException +=new UnhandledExceptionEventHandler(UnhandledExceptionFunction);

　　2. Asp.net，可以在Application_Error()方法里捕获异常

　　3. MVC,可以写ExceptionFilter

　　4. WebApi,可以写ExceptionHandler

　　这里面拿到的Exception都是带整个Stack记录的，你可以用Log4记录下来，并不是有的同学说的只会拿到e.message这样

　　建议：少写Try…Catch,喜欢写Try…Catch的朋友注意：你那90%的Try…Catch都是没必要的。