Atitit 语言的异常机制 目录 1. 异常处理,英文名为exceptional handling, 是代替日渐衰落的error code方法的新法, 1 2. 三种模式 1 2.1. 终止模式

Atitit 语言的异常机制

 

目录

1. 异常处理,英文名为exceptional handling, 是代替日渐衰落的error code方法的新法, 1

2. 三种模式 1

2.1. 终止模式 1

2.2. 恢复执行模式 2

2.3. 选择模式 2

2.4. Java中使用恢复模式 2

3. 推荐流程法 3

4. 异常处理的反模式重大问题 3

4.1. 反例之一:丢弃异常 3

4.2. 反例之二:不指定具体的异常 3

4.3. 反例之三:占用资源不释放 文件、Socket、JDBC连接之类的资源 3

4.4. 反例之四:不说明异常的详细信息 3

4.5. 反例之五:过于庞大的try块 4

4.6. 反例之六:输出数据不完整 4

 

  1. 异常处理,英文名为exceptional handling, 是代替日渐衰落的error code方法的新法,

提供error code 所未能具体的优势。异常处理分离了接收和处理错误代码。这个功能理清了编程者的思绪,也帮助代码增强了可读性,方便了维护者的阅读和理解。

异常处理(又称为错误处理)功能提供了处理程序运行时出现的任何意外或异常情况的方法。异常处理使用 try、catch 和 finally 关键字来尝试可能未成功的操作,处理失败,以及在事后清理资源。

异常处理通常是防止未知错误产生所采取的处理措施。异常处理的好处是你不用再绞尽脑汁去考虑各种错误,这为处理某一类错误提供了一个很有效的方法,使编程效率大大提高。

  1. 三种模式
    1. 终止模式

许多常见的程序设计语言,包括ActionscriptAda,BlitzMax,C++C#DECMAScriptEiffelJavaMLObject Pascal(如DelphiFree Pascal等),Objective-COcamlPHP(version 5),PL/1,PrologPythonREALbasicRubyVisual Prolog以及大多数.NET程序设计语言,内建的异常机制都是沿着函数调用栈的函数调用逆向搜索,直到遇到异常处理代码为止。一般在这个异常处理代码的搜索过程中逐级完成栈卷回(stack unwinding)

    1. 恢复执行模式

。但Common Lisp是个例外,它不采取栈卷回,因此允许异常处理完后在抛出异常的代码处原地恢复执行。

    1. 选择模式

而 Visual Basic(尤其是在其早于 .net 的版本,例如 6.0 中)走得更远:on error 语句可轻易指定发生异常后是重试(resume)还是跳过(resume next)还是执行程序员定义的错误处理程序(goto ***)。 [1] 

多数语言的异常机制的语法是类似的:用throw或raise抛出一个异常对象(Java或C++等)或一个特殊可扩展的枚举类型的值(如Ada语言);异常处理代码的作用范围用标记子句(try或begin开始的语言作用域)标示其起始,以第一个异常处理子句(catch, except, resuce等)标示其结束;可连续出现若干个异常处理子句,每个处理特定类型的异常。某些语言允许else子句,用于无异常出现的情况。更多见的是finally, ensure子句,无论是否出现异常它都将执行,用于释放异常处理所需的一些资源。[1] 

 

    1. Java中使用恢复模式

一种称为"终止模型"(它是Java与C++所支持的模型).在这种模型中,将假设错误非常关键,将以致于程序无法返回到异常发生的地方继续执行.一旦异常被抛出,就表明错误已无法挽回,也不能回来继续执行.

另一种称为"恢复模型".意思是异常处理程序的工作是修正错误,然后重新尝试调动出问题的方法,并认为第二次能成功.

对于恢复模型,通常希望异常被处理之后能继续执行程序.在这种情况下,抛出异常更像是对方法的调用--可以在Java里用这种方法进行配置,以得到类似恢复的行为.(也就是说,不是抛出异常,而是调用方法修正错误.)或者,把try块放在while循环里,这样就可以不断的进入try块,直到得到满意的结果.

虽然恢复模型开始显得很吸引人,并且人们使用的操作系统也支持恢复模型的异常处理,但程序员们最终还是转向了使用类似"终止模型"的代码.因为:处理程序必须关注异常抛出的地点,这势必要包含依赖于抛出位置的非通用性代码.这增加了代码编写和维护的困难,对于异常可能会从许多地方抛出的大型程序来说,更是如此

 

  1. 推荐流程法

 

  1. 异常处理的反模式重大问题

 

    1. 反例之一:丢弃异常
    2. 反例之二:不指定具体的异常

代码:12行。

许多时候人们会被这样一种“美妙的”想法吸引:用一个catch语句捕获所有的异常。最常见的情形就是使用catch(Exception ex)语句。但实际上,在绝大多数情况下,这种做法不值得提倡。为什么呢?

    1. 反例之三:占用资源不释放 文件、Socket、JDBC连接之类的资源

代码:3行-11行。

异常改变了程序正常的执行流程。这个道理虽然简单,却常常被人们忽视。如果程序用到了文件、Socket、JDBC连接之类的资源,即使遇到了异常,也要正确释放占用的资源。为此,Java提供了一个简化这类操作的关键词finally。

    1. 反例之四:不说明异常的详细信息

代码:3行-11行。

仔细观察这段代码:如果循环内部出现了异常,会发生什么事情?我们可以得到足够的信息判断循环内部出错的原因吗?不能。我们只能知道当前正在处理的类发生了某种错误,但却不能获得任何信息判断导致当前错误的原因。

    1. 反例之五:过于庞大的try块

代码:3行-11行。

经常可以看到有人把大量的代码放入单个try块,实际上这不是好习惯。这种现象之所以常见,原因就在于有些人图省事,不愿花时间分析一大块代码中哪几行代码会抛出异常、异常的具体类型是什么。把大量的语句装入单个巨大的try块就象是出门旅游时把所有日常用品塞入一个大箱子,虽然东西是带上了,但要找出来可不容易。

    1. 反例之六:输出数据不完整

代码:7行-8行。

不完整的数据是Java程序的隐形杀手。仔细观察这段代码,考虑一下如果循环的中间抛出了异常,会发生什么事情。循环的执行当然是要被打断的,其次,catch块会执行??就这些,再也没有其他动作了。已经输出的数据怎么办?使用这些数据的人或设备将收到一份不完整的(因而也是错误的)数据,却得不到任何有关这份数据是否完整的提示。对于有些系统来说,数据不完整可能比系统停止运行带来更大的损失。

 

异常处理_百度百科.html

猜你喜欢

转载自blog.csdn.net/attilax/article/details/90957585