你是不是这样写异常处理代码的呢?
- 作者: 我真不认识小智
- 来源: 51数据库
- 2021-09-02
经常看到同事这样写代码:
dataset querydb()
{
dataset ds=null;
try
{
//do something
}
catch (exception ex)
{
//这里要做日志记录
}
return ds;
}
这里有几个问题:
1:很明显,如果querydb方法发生了任何异常,客户端无法得知,例如客户端调用querydb方法,该方法返回了null,那这代表数据库里面没有这个数据呢?还是抛出了异常?
2:注释是不应该存在的,它应该被真实的日志记录代码给替代,例如log.write(ex);
3:该方法捕捉所有异常,这样任何异常都被捕获了,这对于开发很不方便,永远不要捕获你不能处理的异常。
4:为什么这样写代码??解释是:真实用户不希望看到错误信息,初听起来,好像有几分道理,试想没有哪个用户会用你的软件,然后老是抛出个异常什么的,但是这是部署之后的事情啊,而不是开发的程序员不希望看到异常啊。在开发的时候,如果能够看到详细的异常信息,那么可以很快的改正,修复bug,何乐而不为之呢??
于是修改为如下:
dataset querydb()
{
dataset ds = null;
try
{
//do something
}
catch (exception ex)
{
log.write(ex);
throw ex;
}
return ds;
}
好了,现在异常总算被捕获了,并且也被成功了抛出来了。
这段代码还是有问题??
在catch语句块中,throw ex; 最好修改为throw;
因为在.net中,异常都是不可修改的,每一次异常被抛出的时候,异常的堆栈跟踪信息都会被重置,
throw 不会重置堆栈跟踪信息,但是throw ex;会重置。所以为了更方便的查找异常的抛出位置,最好使用throw 语句,而不是throw ex;否则clr会认为异常是在catch语句块中抛出的。
顺便再说一句,不要捕获你不能处理的异常,如果希望将来用户看不到异常信息,
大可以使用appdomain.或者application的全局异常处理。
- C#通过fleck实现wss协议的WebSocket多人Web实时聊天(附源码)
- 团队城市未满足要求:MSBuildTools12.0_x86_Path 存在
- 使用 MSBuild.exe 在发布模式下构建 C# 解决方案
- 当我发布 Web 应用程序时,AfterPublish 脚本不运行
- 构建时 T4 转换的产品仅在下一个构建中使用
- ASP.NET Core Application (.NET Framework) for Windows x64 only error in project.assets.json
- 新的 .csproj 格式 - 如何将整个目录指定为“链接文件"到子目录?
- 如何将条件编译符号(DefineConstants)传递给 msbuild
- MSBuild 支持 Visual Studio 2017 RTM 中的 T4 模板
- NuGet 包还原找不到包,没有源
