- 6 -
class Matherr { };
class Overflow: public Matherr { };
class Underflow: public Matherr { };
class Zerodivide: public Matherr { };
// ...
Such classification is particularly convenient because of the desire to handle similarly any member of a col-
lection of exceptions: it is easy to imagine many reasons why one might want to recover from any kind of
Matherr without caring precisely which kind it was. Using inheritance in this way makes it possible to
say
try {
f();
}
catch (Overflow) {
// handle Overflow or anything derived from Overflow
}
catch (Matherr) {
// handle any Matherr that is not Overflow
}
Here an Overflow is handled specifically, and all other Matherr exceptions will be handled by the
general case. Of course, a program that says catch(Matherr) will not know what kind of Matherr it
has caught; whatever it was, its copy will be a Matherr by the time the handler is entered. We will see
later how a program can cater to a potentially unknown set of exceptions by catching a reference to an
exception.
There are cases where an exception can reasonably be considered to belong to two or more groups. For
example:
class network_file_err : public network_err , public file_system_err { };
Obviously, this too is easily handled without language extensions.
4.1 Naming the Current Exception
We name the current exception analogously to naming the argument of a function:
try { /* ... */ } catch (zaq e) { /* ... */ }
This is a declaration of e with its scope identical to the body of the exception handler. The idea is that e is
created using the copy constructor of class zaq before entering the handler.
Where there is no need to identify the particular exception, there is no need to name the exception
object:
try { /* ... */ } catch (zaq) { /* ... */ }
This again is similar to the technique of not naming unused function arguments in a function definition.
As with functions, the argument declaration (...) accepts any call, so that
catch (...) { /* any exception will get here */ }
will catch every exception. There is no way of finding out what exception caused entry into such a handler.
Were such a way provided, type safety would be compromised and the implementation of exception han-
dling complicated. When a handler is done with an exception, it may sometimes want to re-throw that
exception, whatever it was, without caring what kind of exception it was. To do this, say throw without
specifying an exception:
catch (...) {
// do something
throw; // re-throw current exception
}
Such a re-throw operation is valid only within a handler or within a function called directly or indirectly
from a handler.
剩余30页未读，继续阅读
loveabcc
- 粉丝: 2
- 资源: 22
我的内容管理
展开
最新资源
- Vue实现iOS原生Picker组件：详细解析与实现思路
- Arduino蓝牙小车：参数调试与功能控制
- 百度Java面试精华：200页精选资源涵盖核心知识点
- Swift使用CoreData填坑指南：CoreData在Swift 3.0的变化
- 微距离无线充电器创新设计及其实验探索
- MTK Android平台开发全攻略：44步详解流程
- RecyclerView全面解析：替代ListView的新选择
- Android开发：自动适配中英文键盘解决方案
- Android调用WebService接口教程
- Android开发：BitmapUtil图片处理全解析与实例
- Android多线程断点续传实现详解
- PCA算法在人脸识别会议签到系统中的应用
- EventBus 3.0：Android事件总线详解与实战应用
- Android FileUtil：全面解析文件操作实用技巧与实例
- RecyclerView添加头部和尾部实战教程
- Android实现微博滑动固定顶部栏实战与优化
资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！
点击此处反馈
