| | | .NET异常代码编写 | | 2001-10-17·
·Eric Gunnerson··YESKY
| 1 2 3 4 5 6 下一页
为什么使用异常(Exceptions)
从错误代码转换到异常处理会对你的代码风格产生很大影响。要用一种不同的方法编写程序，需要你培养一套新的编程习惯，在你开始努力这么做之前，这篇文章会让你知道你的努力将非常有意义。
错误代码的使用已经有相当长的一段时间了。如果你在C++ 中编写代码，通常是下面的形式：
HRESULT retval = query.FetchRow();
if (FAILED(retval))
{
// error handling here
} |
使用错误代码的真正问题是返回的代码不是很好。尽管从理论上讲，错误代码可以正确处理程序中所有的错误，但总有一些问题是你无法预先知道的。一些传统编程模型的脆弱性就是源于不正确的错误处理；编写正确的代码并不容易．
问题的症结在于错误代码这种方法要求程序员去完成人类不擅长的工作--任何时候的一致性和完整性，并且系统环境没有给你任何帮助。异常(Exception)将使这一切变得容易很多。
是Opt Out而不是Opt In
错误代码和异常最重要的不同在于对"做正确的事情"的要求不一样。错误代码使用的是Opt in，如果代码中对错误没有做明确的处理，那么这个错误就会被忽略。
而异常(Exceptions)使用的是Opt Out模型。在默认情况下，运行时(runtime)会根据这些异常(exceptions)做正确的处理。
这个区别对编写的代码有着很重要的影响。因为运行时(Runtime)能对问题进行常规的处理，所以程序员就可以将精力放在那些需要特殊处理的问题。这可以使我们能用更少的精力却得到更为健壮的代码。光这一个好处就足以促成向异常(exception)的转变，更何况异常(exception)还有一个重要的优势。
更多的信息
在编写新代码时，写出的代码不能正常工作是很常见的。你可能会从某个函数那得到诸如"0x80001345"类似的返回值，接下来你就不得不想办法判断出其中的含义。
你首先要做的就是把这个返回值翻译成某种类型的符号代码。虽然可能会有更好的办法，但我通常是去查找 .h 文件中的常量。在找到之后，你需要打开MSDN来找出这代码的含义，最后才能决定如何修改程序。这还是在你幸运的情况下，有时候你更本就无法找到与错误码对应的符号代码。
有时候即使你找到了错误代码，也没有什么帮助。如果得到的错误码是ERROR_BAD_ARGUMENTS，我知道这是由给出的某个参数不正确引起的，但我不知道是哪一个。我调用的那个函数虽然知道，但它无法告诉我是哪一个出了问题。
有了异常机制，我除了能得到一个名字告诉我发生了哪一种错误，而且还能得到一个更具体的信息。例如，如果我传递了一个错误的参数，exception会告诉我哪一个参数错了。这节省了大量的时间。
更好的是，exception信息还能给出提示，教你如何去解决问题。今年早些时候，我试着将Beta1 的代码移植到Beta2中，当我运行程序的时候，程序抛出一个如下的异常(exception)：
| "Paint operation cannot be performed on this thread. Use Control.Invoke() instead" |
升级了的Beta2代码会检查不正确的用法，如果找到了，就抛出一个异常(exception)并确切地告诉程序员如何去解决这个问题。要修改这么一个错误真的是很简单。
1 2 3 4 5 6 下一页 | | | 感谢
访问天极网，如果您觉得该文章涉及版权问题，请看这里！
|
|
