Col*_*lin 8 .net c# exception-handling
我们的代码随处可见一般情况.
通常它会将错误写入数据库中的日志表,并向用户显示一个MessageBox,表示请求的操作失败.如果存在数据库交互,则回滚事务.
我已经介绍了一个业务逻辑层和一个数据访问层来解开一些逻辑.在数据访问层中,我选择不捕获任何内容,并且还抛出ArgumentNullExceptions和ArgumentOutOfRangeExceptions,以便从堆栈传递的消息不会直接来自数据库.
在业务逻辑层我放了一个try catch.在catch中我回滚事务,进行日志记录和重新抛出.
在表示层中有另一个显示MessageBox的try catch.
我现在正在考虑捕获DataException和ArgumentException而不是Exception,我知道代码只访问数据库.
在代码访问Web服务的地方,我想我会创建自己的"WebServiceException",只要抛出HttpException,WebException或SoapException,就会在数据访问层中创建它.
所以现在,一般来说,我将捕获2或3个例外,目前我只捕获一般的例外,我觉得这对我来说似乎没问题.是否有人再次包装异常以将消息传递到表示层？
我想我应该向Main()添加一个try catch来捕获Exception,尝试记录它,显示"Application遇到错误"消息并退出应用程序.所以,我的问题是,有没有人在我的计划中看到任何漏洞？是否有任何明显的异常我应该捕捉或做这些几乎覆盖它(除了文件访问 - 我认为只有一个地方我们读写配置文件).
我将使用 try/finally （或等效的 using 语句）进行回滚，而不是在 catch 块中进行回滚。特别是，如果您只捕获特定的异常，那么您仍然希望在抛出意外的异常类型时进行数据库回滚。
除了少数例外，我很少在任何地方使用 catch，除了：
在物理层边界，我在 catch 块中使用 try/catch 和 log/throw ，以便可以在服务器上记录异常。使用 WCF 等较新的技术，无需 try/catch 即可记录异常（例如，使用 WCF DispatchBehavior）。
在表示层的顶级处理程序中。
在业务层和数据层，会有很多try/finally（即using语句），但几乎没有catch。