paras[0].DbType 引发了“System.ArgumentException ”类型的异常

引言

        最近在重构市委组织部考核的项目,但是重构归重构,当初的维护工作还是要继续的,所以,当旧的版本出了新问题或者是用户又有了新的需求,我们还是要满足滴……

        维护工作派发下来,我们各自领取任务,我负责的是开发区附加分编辑不成功的错误。组长说,之前是没有问题的,后来不知道由于修改其他的地方,导致这个地方不能用,让我去仔细的看看。

问题

        代码拿到手,先找到相应的位置,然后一步步的调试,一步步的走代码,之前的每一步都没有问题,而且都查到了数据,唯独最后编辑之后更新数据的时候,就不跳了,也不报错,这可让我苦恼了。各种查,各种百度,但是不知道问题在哪。

       最后我就在点那些跟踪到的语句,在赋值的上一句点开了详细的信息查看,才发现了一个异常。

paras[0].DbType 引发了“System.ArgumentException ”类型的异常_第1张图片

解决   

       不知道这个异常是什么原因,所以直接百度的。查到的的答案是把触发这个方法的try/catch语句去掉。

paras[0].DbType 引发了“System.ArgumentException ”类型的异常_第2张图片


分享

        现在问题解决了,我们来普及一下异常处理的知识。

        早起的Win32API设计中是通过返回true/false来表示一个过程(方法、函数)是否执行成功,在COM中使用HRESULT来表示一个过程是否正确执行,然而这种处理异常的方式使开发人员对哪里出错,为什么出错,出什么样的错这些问题很难找到明确的答案,再一点,调用者很容易忽略一个过程执行的结果,如果调用者丢弃了过程执行结果,则代码将“按照期望的状态正常执行”,这是很危险的。后来,在.NET Framework中,已经不再使用这种简单的以状态码来表示执行结果的处理方式,而是使用抛出异常的方式来告诉调用者:兄弟,出错了!如果你不赶紧修复,系统将让你无法进行!

        CLR中的异常是基于SEH的结构化异常处理机制构建的,在基础的SHE机制中是向系统注册出错时的回调函数,当在监视区内出错时,系统会取得当前线程的控制权处理回调函数,处理完毕后,系统释放控制权给当前线程,当前线程继续执行,如果未处理异常的代码段,会导致进程中止。

CLR在对SEH封装的基础上以更优雅的方式向开发人员提供良好的编程体验,它把异常处理分为三块try、catch、finally。

        Try块是监视区,其内放置一些正常实现编程功能的代码、资源清除的代码、状态维护(状态改变和状态恢复)的代码等。

        Catch块捕获区,当try块出现异常时,如果异常类型与该区域期望的类型一致,则执行此区域的代码,可以进行状态恢复,也可以重新抛出异常。一个try块可以多个catch块,也可以无catch块。

         Finally块作最后清理工作,在一个try/catch结构中,无论try是否抛出异常,无论catch是否破获到异常,如果有finally块,在最后都会执行,通常在这里放置资源清理的代码。一个try结构可有finally块,也可以没有。

         需要注意的是,一个try块必须有一个catch块或finally块与其对应,如下几种使用方式都是可以的:try…catch 、try…finally、try…catch.finally。


样例

<span style="font-size:18px;">Try
{
//这的代码是程序的主体。其中的代码可能引发错误。
}
Catch(e Error1 )//处理错误类型Error1
{
//这的代码是错误的处理程序
}
Catch(e Error2 )//处理错误类型Error2
{
//这的代码是错误的处理程序
} 
……
Finally//可以不写,但是写了就一定会执行
{
//这里的代码一定会被执行
}
</span>


总结

        我们在生活中都喜欢优雅的美女,那么让我们的代码也变得优雅吧。使用trycatch 语句,但是用的时候一定要合适,不能乱用。否则也会像小编出了错之后找不到头绪。。。。这样出了错也好,让我们的在错误中更强壮!

你可能感兴趣的:(paras[0].DbType 引发了“System.ArgumentException ”类型的异常)