1. 异常规格申明
现在是探索C++标准运行库和Visual C++在头文件<exception>中申明的异常支持的时候了。根据C++标准(subclause 18.6,“Exception handling” )上的描述,这个头文件申明了:
l 从运行库中抛出的异常对象的基类。
l 任何抛出的违背异常规格申明的对象的可能替代物。
l 在违背异常规格申明的异常被抛出是被调用的函数,以及在其行为上增加东西的钩子(“hook”)。
l 在异常处理过程被终止时被调用的函数,以及在其行为上增加东西的钩子。
我从分析异常规格申明及程序违背它时遭到什么可怕后果开始。分析将针对上面提到的主题,以及通常C++异常处理时的一些杂碎。
1.1 异常规格申明回顾
异常规格申明是C++函数申明的一部分,它们指定了函数可以抛出什么异常。例如,函数
void f1() throw(int)
可以抛出一个整型异常,而
void f2() throw(char *, E)
可以抛出一个char *或一个E(这里E是用户自定义类型)类型的异常。一个空的规格申明
void f3() throw()
表明函数不抛出异常,而没有规格申明
void f4()
表明函数可以抛出任何东西。注意语法
void f4() throw(...)
比前面的“抛任何东西”的函数更好,因为它类似“捕获任何东西”
catch(...)
然而,认可“抛任何东西” 的函数就允许了那些在异常规格申明存在前写下的函数。
1.2 违背异常规格申明
迄今为止,我写的都是:函数可能抛出在它的异常规格申明中描述的异常。“可能”有些单薄,“必须”则有力些。“可能”表示了函数可以忽略它们的异常规格。你也许认为编译器将禁止这种行为:
void f() throw() // Promises not to throw...
{
throw 1; // ...but does anyway - error?
}
但你错了。用Visual C++试一下,你将发现编译器保持沉默,它没有发现编译期错误。实际上,在我所用过的编译器中,没有一个报了编译期错误。
话虽这么说,但异常规格申明有它的规则的,函数违背它将遭受严重后果的。不幸的是,这些后果表现在运行期错误而不是编译期。想看的话,把上面的小段代码放到一个完整程序中:
void f() throw()
{
throw 1;
}
int main()
{
f();
return 0;
}
当程序运行时将发生什么?f()抛出一个int型异常,违背了它的契约。你可能认为这个异常将从main()中漏入运行期库。基于这个假设,你倾向于使用一个简单的try块:
#include <stdio.h>
void f() throw()
{
throw 1;
}
int main()
{
try
{
f();
}
catch (int)
{
printf("caught int/n");
}
return 0;
}
来捕获这个异常,以防止它漏出去。
实际上,如果你用Visual C++ 6编译并运行,你将得到:
caught int
你再次奇怪throw()异常规格实际做了什么有用的事,除了增加了源代码的大小和看起来比较快感。你的奇怪感觉将变得迟钝,只要一回想到前面说了多少Visual C++违背C++标准的地方,只不过再多一个新问题:Visaul C++正确地处理了违背异常规格申明的情况了吗?
1.3 调查说明……
没有!
这个程序的行为符合标准吗?catch语句不该进入的。来自于标准(subclauses 15.5.2 and 18.6.2.2):
l 一个异常规格申明保证只有被列出的异常被抛出。
l 如果带异常规格申明的函数抛出了一个没有列出的异常,函数
l void unexpected()在退完栈后立即被调用。
l 函数unexpected()将不会返回……
当一个函数试图抛出没有列出的异常时,通过unexpected()函数调用了一个异常处理函数。这个异常处理函数的默认实现是调用terminate() 来结束程序。
在我给你一个简短的例程后,我将展示Visual C++的行为怎么样地和标准不同。
1.4 unexpected()函数指南
unexpected()函数是标准运行库在头文件<exception>中申明的函数。和其它大部分运行库函数一样,unexpected()函数存在于命名空间std中。它不接受参数,也不返回任何东西,实际上unexpected()函数从不返回,就象abort()和exit()一样。如果一个函数违背了它自己的异常规格申明,unexpected()函数在退完栈后被立即调用。
基于我对标准的理解,运行库的unexpected()函数的实现理论上是这样的:
void _default_unexpected_handler_()
{
std::terminate();
}
std::unexpected_handler _unexpected_handler =
_default_unexpected_handler;
void unexpected()
{
_unexpected_handler();
}
(_default_unexpected_handler和_unexpected_handler是我虚构的名字。你的运行库的实现可能使用其它名称,完全取决于其实现。)
std::unexpected()调用一个函数来真正处理unexpected的异常。它通过一个隐藏的指针(_unexpected_handler,类型是std::unexpected_handler)来引用这个处理函数的。运行库提供了一个默认处理函数(default_unexpected_handler()),它调用std::terminate()来结束程序。
因为是通过指针_unexpected_handler间接调用的,你可以将内置的调用_default_unexpected_handler改为调用你自己的处理函数,只要这个处理函数的类型兼容于std::unexpected_handler:
typedef void (*unexpected_handler)();
同样,处理函数必须不返回到它的调用者(std::unexpected())中。没人阻止你写一个会返回的处理函数,但这样的处理函数不是标准兼容的,其结果是程序的行为有些病态。
你可以通过标准运行库的函数std::set_unexpected()来挂接自己的处理函数。注意,运行库只维护一个处理函数来处理所有的unexpected异常;一旦你调用了set_unexpected()函数,运行库将不再记得前一次的处理函数。(和atexit()比较一下,atexit()至少可以挂32重exit处理函数。)要克服这个限制,你要么在不同的时间设置不同的处理函数,要么使你的处理函数在不同的上下文时有不同的行为。
1.5 Visual C++ vs unexpected
试一下这个简单的例子:
#include <exception>
#include <stdio.h>
#include <stdlib.h>
using namespace std;
void my_unexpected_handler()
{
printf("in unexpected handler/n");
abort();
}
void throw_unexpected_exception() throw(int)
{
throw 1L; // violates specification
}
int main()
{
set_unexpected(my_unexpected_handler);
throw_unexpected_exception();
printf("this line should never appear/n");
return 0;
}
用一个标准兼容的编译器编译并运行,程序结果是:
in unexpected handler
可能接下来是个异常异常终止的特殊(因为有abort()的调用)。但用Visual C++编译并运行,程序会抛出“Unhandled exception”对话框。关闭对话框后,程序输出:
this line should never appear
必须承认,Visual C++没有正确实现unexpected()。这个函数被申明在<exception>中,运行期库中有其实现,只不过这个实现不做任何事。
实际上,Visual C++甚至没有正确地申明,用这个理论上等价的程序可以证明:
#include <exception>
#include <stdio.h>
#include <stdlib.h>
//using namespace std;
void my_unexpected_handler()
{
printf("in unexpected handler/n");
abort();
}
void throw_unexpected_exception() throw(int)
{
throw 1L; // violates specification
}
int main()
{
std::set_unexpected(my_unexpected_handler);
throw_unexpected_exception();
printf("this line should never appear/n");
return 0;
}
Visual C++不能编译这个程序。查看<exception>表明:set_unexpected_handler()被申明为全局函数而不是在命名空间std中。实际上,所有的unexpected族函数都被申明为全局函数。
底线:Visual c++能编译使用unexpected()等函数的程序,但运行时的行为是不正确的。
我希望Microsoft能在下一版中改正这些问题。在未改正前,当讨论涉及到unexpected()时,我建议你使用标准兼容的C++编译器。
1.6 维持程序存活
在我所展示的简单例子中,程序在my_unexpected_handler()里停止了。有时,让程序停止是合理和正确的;但更多情况下,程序停止是太刺激了,尤其是当unexpected异常表明的是程序只轻微错误。
假定你想处理unexpected异常,并恢复程序,就象对大多数其它“正常”异常一样。因为unexpected()从不返回,程序恢复似乎不可能,除非你看了标准的subclause 15.5.2:
unexpected()不该返回,但它可以throw(或re-throw)一个异常。如果它抛出一个新异常,而这异常是异常规格申明允许的,搜索另外一个异常处理函数的行为在调用unexpected()的地方继续进行。
太好了!如果my_unexpected_handler()抛出一个允许的异常,程序就能从最初的违背异常规格申明的地方恢复了。在我们的例子里,最初的异常规格申明允许int型的异常。根据上面的说法,如果my_unexpected_handler抛出一个int异常,程序将能继续了。
基于这种猜测,试一下:
#include <exception>
#include <stdio.h>
void my_unexpected_handler()
{
printf("in unexpected handler/n");
throw 2; // allowed by original specification
//abort();
}
用标准兼容的编译器编译运行,程序输出:
in unexpected handler
program resumed
和期望相符。
抛出的int异常和其它异常一样顺调用链传递,并被第一个相匹配的异常处理函数捕获。在我们的例子里,程序的控制权从my_unexpected_handler()向std::unexpected()再向main()回退,并在main()中捕获异常。用这种方法,my_unexpected_handler()变成了一个异常转换器,将一个最初的“坏”的long型异常转换为一个“好”的int型异常。
结论:通过转换一个unexpected异常为expected异常,你能恢复程序的运行。
1.7 预告
下次,我将结束std::unexpected()的讨论:揭示在my_unexpected_handler()中抛异常的限制,探索运行库对这些限制的补救,并给出处理unexpected异常的通行指导原则。我也将开始讨论运行库函数std::terminate()的相关内容。
void throw_unexpected_exception() throw(int)
{
throw 1L; // violates specification
}
int main()
{
std::set_unexpected(my_unexpected_handler);
try
{
throw_unexpected_exception();
printf("this line should never appear/n");
}
catch (int)
{
printf("program resumed/n");
}
return 0;
}