DbC vs. Exception - PDF Free Download

DbC vs. Exception 契约式设计 vs. 异常

Exception 问题何谓异常 (Exception)? 一种情况要异常到什么程度才算异常? 为什么要引入异常处理机制? Robustness? Readability? 如何进行异常处理? Mandatory or Optional 不同的认识, 不同的答案 Java/C++/C# Eiffel

Java Exception Mechanisms 3 Java 对 Exception 的界定较宽因而需认真区分不同类型的 Exceptions Java 的 Exception 机制回顾 try/catch/finally throw Exceptions 自定义 Exceptions Java Exception 与 Design by Contract Exception 的转换

What are Exceptions? Many exceptional things can happen during the running of a program, e.g.: User mis-types input Web page not available Array index out of bounds Method called on a null object Out of memory File not found Divide by zero Bug in the actual language implementation Exceptions are unexpected conditions in programs. checked unchecked sys errors 4

We can distinguish 3 categories: checked exceptions Problems to do with the program's interaction with the world. The world is unpredictable, so we would expect these things to happen in production code, and so need to handle them. The World Checked Exceptions Program System 5

We can distinguish 3 categories: checked exceptions Problems to do with the program's interaction with the world. unchecked exceptions Problems within the program itself (i.e. violations of the contract, or bugs). The World These should be removed by testing, and not occur in production code. Checked Exceptions Unchecked Exceptions Program System 6

We can distinguish 3 categories: checked exceptions Problems to do with the program's interaction with the world. unchecked exceptions Problems within the program itself (i.e. violations of the contract, or bugs). system errors Problems with the underlying system. These are outside our control. Unchecked Exceptions The World Program System Checked Exceptions System Errors 7

Checked vs Unchecked Exceptions an important distinction, which the Java Exception class hierarchy does make, but in a rather confusing way 8

Checked vs Unchecked Exceptions it's normal to let these just crash the program so we can debug it. we would normally check for these, and deal with them when they occur. Unchecked Exceptions The World Program System Checked Exceptions System Errors Exception handling is the business of handling these things appropriately. 9

Exception Hierarchy in Java Throwable Error Exception RuntimeException... RuntimeException The World Checked Exceptions Exception RuntimeException Unchecked Exceptions Program System System Errors Error 10

What do we want of exceptions? Ideally, a language (and its implementation) should: Restrict the set of possible exceptions to reasonable ones e.g. no pointers to deallocated memory 11

What do we want of exceptions? Ideally, a language (and its implementation) should: Restrict the set of possible exceptions to reasonable ones Indicate where they happened, and distinguish between them Allow exceptions to be dealt with in a different place in the code from where they occur so normal case code can be written cleanly without having to worry about them 13

What do we want of exceptions? Ideally, a language (and its implementation) should: Restrict the set of possible exceptions to reasonable ones Indicate where they happened, and distinguish between them Allow exceptions to be dealt with in a different place in the code from where they occur so we throw exceptions where they occur, and catch them where we want to deal with them. 14 Ideally, we don't want non-fatal exceptions to be thrown too far this breaks up the modularity of the program and makes it hard to reason about.

Exceptions in Java a reminder In Java, the basic exception handling construct is to: try a block of code which normally executes ok catch any exceptions that it generates, and finally do anything we want to do irrespective of what happened before. If a thrown exception is not caught, it propagates out to the caller and so on until main. If it is never caught, it terminates the program. If a method can generate (checked) exceptions but does not handle them, it has to explicitly declare that it throws them so that clients know what to expect. 15

The Throwable Class Hierarchy The standard API defines many different exception types basic ones in java.lang others in other packages, especially java.io Throwable Top level class is not Exception but Throwable. Error Exception RuntimeException... 16

Throwable Error Exception Problems with the underlying Java platform, e.g. VirtualMachineError. RuntimeException... User code should never explicitly generate Errors. This is not always followed in the Java API, and you may occasionally need to say catch (Throwable e) to detect some bizarre error condition 17

Throwable Error Exception Problems with the underlying Java platform, e.g. VirtualMachineError. RuntimeException... User code should never explicitly generate Errors. In general, you want to catch specific sorts of (checked) exceptions, and saying catch (Exception e) is bad style. never mind Throwable! 18

Throwable Error Exception RuntimeException... Unchecked exceptions are subclasses of RuntimeException It would be much clearer if this was called UncheckedException These include our old friends NullPointerException and ArrayIndexOutOfBoundsException. Virtually any method can in principle throw one or more of these, so there's no requirement to declare them in throws clauses. 19

Throwable Error Exception All other exceptions are checked exceptions RuntimeException... It would be nice if there was a class CheckedException. 20

Throwable Error Exception All other exceptions are checked exceptions RuntimeException... The most common ones are IOExceptions such as FileNotFoundException. If you write code which can throw one of these, you must either catch it or declare that the method throws it. The compiler goes to enormous lengths to enforce this, and related constraints, e.g. that all overridden versions of a method have consistent throws clauses. 21

Exception Handling and DbC Exceptions are about dealing with things going wrong at runtime. DbC is about statically defining the conditions under which code is supposed to operate. (The two are nicely complementary.) Unchecked exceptions are what happens when the contract is broken Checked exceptions are expected so are not contract violations. to happen from time to time e.g. if a precondition that an array has at least one element is broken, an ArrayIndexOutOfBoundsException will probably occur. 22

So if we're going to use DbC,we ought to structure our code into: code which deals with The World Methods doing this will have no (or weak) preconditions, and will deal with problems via exception handling. 23

So if we're going to use DbC,we ought to structure our code into: code which deals with The World code which is insulated from The World. This can have strong preconditions and won't throw exceptions (apart from unchecked ones during debugging). 24

So if we're going to use DbC,we ought to structure our code into: code which deals with The World code which is insulated from The World. E.g. an application involving form-filling should have code which validates the user input for type-correctness etc. code which relies on the input being correct to process it If these two sorts of operations are mixed together, the application will probably be harder to maintain and more error-prone. 25

Converting Exceptions Good OO design decouples things. E.g. in most patterns there's a Client class which delegates operations to some black box in the pattern. Client op Black box some application-specific code some application-independent library What happens if the black box throws a (checked) exception? 27

Converting Exceptions Good OO design decouples things. E.g. in most patterns there's a Client class which delegates operations to some black box in the pattern. Client op Black box some application-specific code may have its own exception types, but they need to be applicationspecific. some application-independent library exceptions thrown from within the library will be applicationindependent. 28

try {... obj.delegateop(...);... } catch (ApplicationIndependentException e){ throw new ApplicationSpecificException(e); } ApplicationSpecificException will therefore have a constructor which takes an ApplicationIndependentException extracts the relevant information and re-casts it in application-specific terms. 29

Example Consider a compiler for an oo language In such a compiler, it's useful to have an explicit representation of the inheritance hierarchy of the source program as a tree (or graph). 30

Example Consider a compiler for an oo language which has an application-independent Hierarchy class which represents a hierarchy of arbitrary key-value pairs. The key is the class name and the value is the definition of the class. 31

Example Consider a compiler for an oo language which has an application-independent Hierarchy class which represents a hierarchy of arbitrary key-value pairs. If something goes wrong in building or using a Hierarchy an InvalidHierarchyException is thrown. e.g. a node has no parent, or there's a cycle 32

33 Example Consider a compiler for an oo language which has an application-independent Hierarchy class which represents a hierarchy of arbitrary key-value pairs. If something goes wrong in building or using a Hierarchy an InvalidHierarchyException is thrown. If this occurs while the class hierarchy is being built, it means the user has mis-spelt a class name or whatever. The InvalidHierarchyExcetpion is converted to a (checked) IllegalInheritanceException resulting in a suitable error message being displayed to the user. If it happens later, an (unchecked) CompilerBrokenExpection is thrown instead, because it means there's a bug in the compiler.

Summary Exception handling is an important, highly integrated, part of the Java system, one of the Really Neat Things About Java. Unchecked exceptions routinely occur during debugging, and make that process much easier. By product shipping time, they should no longer occur. Checked exceptions happen when the program's interaction with the world departs from the normal case. Make sure you handle them appropriately. In particular, think hard about where to handle an exception, so as to simplify the normal-case code, but not to do the handling so far away that modularity is compromised. Application-independent exceptions need to be converted to application-specific ones. 34

Eiffel Exception 机制简介 35 Eiffel 观点 : 契约破坏才会有 Exception Eiffel Exception 机制的设计基于此观点

Basic Concepts 36 The need for exceptions arises when the contract is broken.

Basic Concepts 37 Exception: an undesirable event occurs during the execution of a routine as a result of the failure of some operation called by the routine.

The original strategy 38 r (...) is require do ensure end... op1 op2... opi... opn... Fails, triggering an exception in r (r is recipient of exception).

Causes of exceptions 39 Assertion violation Void call (x.f with no object attached to x) Operating system signal (arithmetic overflow, no more memory, interrupt...)

Handling exceptions properly 41 Safe exception handling principle: There are only two acceptable ways to react for the recipient of an exception: Failure (Organized Panic 合理组织的恐慌 ): clean up the environment, terminate the call and report failure to the caller. Panic: making sure that the caller gets an exception Organized: restoring a consistent execution state Retrying: Try again, using a different strategy (or repeating the same strategy).

How not to do things? 42 (From an Ada textbook) sqrt (x: REAL) return REAL is begin exception if x < 0.0 then else end raise Negative; normal_square_root_computation; Give up and return to the caller as if everything was fine, although not when Negative => put ("Negative argument"); return; when others => end; -- sqrt

The call chain 43 r0 Routine call r1 r2 r3 r4

Exception mechanism 44 Two constructs: A routine may contain a rescue clause. A rescue clause may contain a retry instruction. A rescue clause that does not execute a retry leads to failure of the routine (this is the organized panic case). Failure Principle If an exception occurs in a routine without rescue clause it will cause the routine to fail, trigger an exception in its caller.

45 Transmitting over an unreliable line (1) Max_attempts: INTEGER is 100 attempt_transmission (message: STRING) is -- Transmit message in at most local do rescue -- Max_attempts attempts. failures: INTEGER unsafe_transmit (message) failures := failures + 1 if failures < Max_attempts then retry end end

46 Transmitting over an unreliable line (2) Max_attempts: INTEGER is 100 failed: BOOLEAN attempt_transmission (message: STRING) is -- Try to transmit message; -- if impossible in at most Max_attempts -- attempts, set failed to true. local failures: INTEGER do if failures < Max_attempts then unsafe_transmit (message) else failed := True end rescue failures := failures + 1 retry end

If no exception clause (1) 47 Absence of a rescue clause is equivalent, in first approximation, to an empty rescue clause: f (...) is do... end is an abbreviation for f (...) is do... rescue end -- Nothing here (empty instruction list) (This is a provisional rule; see next.)

The correctness of a class 48 create a.make ( ) S1 For every exported routine r: {INV and Prer} dor {Postr and INV} For every creation procedure cp: {Precp} docp {Postcp and INV} S2 S3 S4 a.f ( ) a.g ( ) a.f ( )

Exception correctness: A quiz 49 For the normal body: {INV and Prer} dor {Postr and INV} For the exception clause: {??? } rescuer {??? } Should it be lazy? Weakest? Strongest? The stronger the precond, the easier the job

Quiz answers 50 For the normal body: {INV and Prer} dor {Postr and INV} For the rescue clause: {True} rescuer {INV} For the retry-introducing rescue clause: {True} retryr {INV and Prer }

Separation of roles 51 Normal body: ensure the routine s contract; not directly to handle exceptions Rescue clause: handle exceptions, returning control to the body or (in the failure case) to the caller; not to ensure the contract.

If no exception clause (2) 52 Absence of a rescue clause is equivalent to a default rescue clause: f (...) is do... end is an abbreviation for f (...) is do... rescue end default_rescue The task of default_rescue is to restore the invariant.

For finer-grain exception handling 53 Use class EXCEPTIONS from the Kernel Library. Some features: exception (code of last exception that was triggered). assertion_violation, etc. raise ( exception_name )

小结 54 使用 Eiffel Exception 机制来构造 Robust 的软件使用 Java/C++/C# Exception 机制来构造 Robust Correct Easy-to-Read

作业 55 解释 checked exception, unchecked exception 和 error 三者的定义以及使用的区别从 DbC 的角度看,Java 方法声明中的 throws 子句反映了类 (supplier ) 和其使用者 (client) 之间的怎样的权利 / 义务关系?Java 子类若重定义父类中的方法, 其 throws 的异常有何限制? 用 DbC 的 Contract 继承原则解释这个限制 4 月 11 日晚上 24:00 前提交至 OODClass@163.com 邮件附件以及主题命名形式, 第四次作业 - 学号 - 姓名.XXX

Java Exception 56 Java Exception 机制的不当使用 : 引自网络论坛 : http://www.chinaunix.net/forum/viewtopic.php?t=136123

1 OutputStreamWriter out =... 2 java.sql.connection conn =... 3 try { // ⑸ 4 Statement stat = conn.createstatement(); 5 ResultSet rs = stat.executequery( 6 "select uid, name from user"); 7 while (rs.next()) 8 { 9 out.println("id:" + rs.getstring("uid") // ⑹ 10 ", 姓名 :" + rs.getstring("name")); 11 } 12 conn.close(); // ⑶ 13 out.close(); 14 } 15 catch(exception ex) // ⑵ 16 { 17 ex.printstacktrace(); //⑴,⑷ 18 } 57

1 OutputStreamWriter out =... 2 java.sql.connection conn =... 3 try { // ⑸ 4 Statement stat = conn.createstatement(); 5 ResultSet rs = stat.executequery( 6 "select uid, name from user"); 7 while (rs.next()) 8 { 9 out.println("id:" + rs.getstring("uid") // ⑹ 10 ", 姓名 :" + rs.getstring("name")); 11 } 12 conn.close(); // ⑶ (1) 丢弃异常! 13 out.close(); 14 } 15 catch(exception ex) // ⑵ 16 { 17 ex.printstacktrace(); //⑴,⑷ 18 } 58

Anti-pattern 59 丢弃异常 - 改正方案 1. 处理异常针对该异常采取一些行动, 例如修正问题提醒某个人或进行其他一些处理, 要根据具体的情形确定应该采取的动作再次说明, 调用 printstacktrace 算不上已经处理好了异常 2. 重新抛出异常处理异常的代码在分析异常之后, 认为自己不能处理它, 重新抛出异常也不失为一种选择 3. 把该异常转换成另一种异常大多数情况下, 这是指把一个低级的异常转换成应用级的异常 ( 其含义更容易被用户了解的异常 ) 4. 不要捕获异常结论一 : 既然捕获了异常, 就要对它进行适当的处理不要捕获异常之后又把它丢弃, 不予理睬

1 OutputStreamWriter out =... 2 java.sql.connection conn =... 3 try { // ⑸ 4 Statement stat = conn.createstatement(); 5 ResultSet rs = stat.executequery( 6 "select uid, name from user"); 7 while (rs.next()) 8 { 9 out.println("id:" + rs.getstring("uid") // ⑹ 10 ", 姓名 :" + rs.getstring("name")); 11 } 12 conn.close(); // ⑶ (2) 不指定具体的异常! 13 out.close(); 14 } 15 catch(exception ex) // ⑵ 16 { 17 ex.printstacktrace(); //⑴,⑷ 18 } 60

Anti-pattern 61 不指定具体的异常改正方案找出真正的问题所在,IOException? SQLException? 结论二 : 在 catch 语句中尽可能指定具体的异常类型, 必要时使用多个 catch 不要试图处理所有可能出现的异常

Anti-pattern 63 占用资源不释放改正方案异常改变了程序正常的执行流程如果程序用到了文件 Socket JDBC 连接之类的资源, 即使遇到了异常, 也要正确释放占用的资源 try/catch/finally 结论三 : 保证所有资源都被正确释放充分运用 finally 关键词

Anti-pattern 65 不说明异常的详细信息改正方案 printstacktrace 的堆栈跟踪功能显示出程序运行到当前类的执行流程, 但只提供了一些最基本的信息, 未能说明实际导致错误的原因, 同时也不易解读结论四 : 在异常处理模块中提供适量的错误原因信息, 例如当前正在执行的类方法和其他状态信息, 包括以一种更适合阅读的方式整理和组织 printstacktrace 提供的信息使其易于理解和阅读

Anti-pattern 67 过于庞大的 try 块改正方案庞大的原因? 偷懒? 结论五 : 分离各个可能出现异常的段落并分别捕获其异常, 尽量减小 try 块的体积

Anti-pattern 69 输出数据不完整改正方案对于有些系统来说, 数据不完整可能比系统停止运行带来更大的损失方案 1: 向输出设备写一些信息, 声明数据的不完整性 ; 方案 2: 先缓冲要输出的数据, 准备好全部数据之后再一次性输出结论六 : 全面考虑可能出现的异常以及这些异常对执行流程的影响

OutputStreamWriter out =... java.sql.connection conn =... try { Statement stat = conn.createstatement(); ResultSet rs = stat.executequery( "select uid, name from user"); while (rs.next()) { out.println("id:" + rs.getstring("uid") + ", 姓名 : " + rs.getstring("name")); } } catch(sqlexception sqlex) { out.println(" 警告 : 数据不完整 "); throw new ApplicationException( " 读取数据时出现 SQL 错误 ", sqlex); } catch(ioexception ioex) { throw new ApplicationException( " 写入数据时出现 IO 错误 ", ioex); } 70 finally { if (conn!= null) { try { conn.close(); } catch(sqlexception sqlex2) { System.err(this.getClass().getName() + ".mymethod - 不能关闭数据库连接 : " + sqlex2.tostring()); } } if (out!= null) { try { out.close(); } catch(ioexception ioex2) { System.err(this.getClass().getName() + ".mymethod - 不能关闭输出文件 " + ioex2.tostring()); } } }

Effective Java Exceptions 71 高效 Java 异常处理机制 : 引自 <<Effective Java TM 语法词汇用法 second edition>>(joshua Bloch) 高效灵活鲁棒可重用的程序

9 大原则 72 Use exceptions only for exceptional conditions 只针对不正常的条件才使用异常 //Horrible abuse of exceptions. Don t ever do this! try{ int i = 0; while(true) range[i++].climb(); }catch(arrayindexoutofboundsexception e) { } 通过 ArrayIndexOutOfBoundsException 的手段来达到终止无限循环的目的 for (Mountain m : range) m.climb();

9 大原则 Use checked exceptions for recoverable conditions and runtime exceptions for programming errors 对于可恢复的条件使用被检查的异常, 对于程序错误使用运行时异常

9 大原则 Avoid unnecessary use of checked exceptions 避免不必要地使用被检查的异常

9 大原则 75 Favor the use of standard exceptions 尽量使用标准的异常 Throw exceptions appropriate to the abstraction 抛出的异常要适合于相应的抽象 Document all exceptions thrown by each method 每个方法抛出的异常都要有文档

9 大原则 76 Include failure-capture information in detail messages 在细节消息中包含失败捕获信息 Strive for failure atomicity 努力使失败保持原子性 Don t ignore exceptions 不要忽略异常

Keep in mind 77 勿以恶小而为之, 勿以善小而不为