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

引言

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

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

问题

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

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

解决   

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

分享

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

        早起的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。

样例

Try
{
//这的代码是程序的主体。其中的代码可能引发错误。
}
Catch(e Error1 )//处理错误类型Error1
{
//这的代码是错误的处理程序
}
Catch(e Error2 )//处理错误类型Error2
{
//这的代码是错误的处理程序
} 
……
Finally//可以不写，但是写了就一定会执行
{
//这里的代码一定会被执行
}

总结

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