04讲_异常错误处理中的安全.pptVIP

程序中的异常，是就地处理比较好还是向客户端传递比较好？此处要遵循下列原则： 1：就地处理方法可以很方便地定义提示信息，对于一些比较简单的异常处理，可以选用这种方法。 2：向客户端传递的方法，其优势在于可以充分发挥客户端的能力，如果异常的处理依赖于客户端，或者某些处理过程在本地无法完成，就必须向客户端传递。举一个例子，如数据库连接代码，可能出现异常，但是异常的处理最好传递给客户端，因为客户端在调用这块代码的同时，可能要根据实际情况，获取环境参数，进行比较复杂的处理。 这样做的好处是：在客户端可以进行更为丰富的异常处理，不仅增加了可扩展性，也可以做到更加安全的代码保障。所以，一般情况下，模块中的异常，如果确定可以就地处理则可，否则就应该向客户端抛出。 不过，异常不断向客户端抛出，会增加系统开销。实际上，在自定义异常的时候也会遇见相同的问题，其原则类似。 提示： 为什么要自定义异常？ 异常的处理可以让我们的软件界面更加友好，并且更加安全。但是有可能我们需要设计类库中没有出现过的异常。 如前面的例子中，如果操作员输入错误的格式，如“1o”、“dsf”等，用传统的异常处理技术，系统会打印“输入格式错误”，达到了要求； 但是，此时如果需要将异常信息和异常出现的时间都封装在一起，作为一个整体抛出，怎么办呢？此时就可以定义一种新的异常，封装异常信息和发生的时间，这就是自定义异常。 很多语言中都有自定义异常的知识，读者可以查阅相关的参考资料。 4.4 面向过程异常处理中的安全问题 4.4.1 面向过程的异常处理 综合各种语言的特性，异常处理机制一共有两种： 1：面向对象的异常处理机制。主要针对面向对象的语言，一般是使用try-catch-finally结构来处理异常，前面所叙述的异常处理机制都是面向对象的异常处理机制。 2：面向过程的异常处理机制。实际上，对于一些非面向对象的语言，如VB，早期也具有异常处理机制，这就是面向过程的异常处理机制。甚至在面向对象的语言，如VB.net中，除了推出面向对象的异常处理机制外，也保留了面向过程的异常处理机制。主要以On Error结构为代表。 不可否认，try结构让异常处理变得更加轻松、异常的层次更为清晰。但是由于On Error结构的灵活性，加之某些语言面向过程的特性，On Error也具有大量的使用场合。 注意，On Error虽然有“Error”这个词语，但是处理的大部分都是异常出现的场合，异常和错误是不同的概念，本书中主要是针对异常进行讲解。 On Error的使用主要有如下方式： 1：使用On Error Resume Next以忽略错误 On Error Resume Next语句规定，代码中的错误将完全被忽略，存在错误的代码行被跳过，然后继续执行下一个语句。 以用户输入一个数字，打印其平方，VB.net为例，编写代码如P04_07.vb 。 该代码如果用户输入正确的数值，能够打印正确结果： 但是如果输入格式错误的数值，则会出现异常： 如果用On Error Resume Next来处理异常，可以改为P04_08.vb。 如果输入格式错误格式的数值： 可见，在出现异常时，程序可以忽略，继续向下执行。该方法对异常进行处理最简单，但是也最不安全。 2：使用On Error GoTo转移执行的代码流 许多情况下，当出现代码错误时，必须执行某些操作，将代码的执行转移到On Error GoTo语句中指定的错误处理程序。该语句的句法如下： 使用较多的是lable，line/lable必须是指与On Error GoTo语句相同的过程中的一个语句。 看代码P04_08.vb ，当用户输入格式错误时，程序能够处理异常。 On Error GoTo line/lable 4.4.2 安全准则 面向过程的异常处理中，为了保证程序安全性，必须注意以下几个准则： 1：On Error Resume Next语句虽然简单，但是由于没有对异常进行处理，因此也是最危险的方法。除非十分确定异常不用专门处理，否则不要使用On Error Resume Next语句。 2：On Error GoTo语句，可以较好地进行异常处理。并且可以随意GoTo，理论上讲，可以跳到程序的任意部位来处理异常，比较灵活，使用场合较多。但是，大量使用GoTo，会让程序逻辑相对复杂，反而造成其他的逻辑上的安全隐患。因此，On Error GoTo语句不宜使用太复杂。一般情况下，程序中最好将处理异常的代码放在统一的地方。在要处理多种异常时，可使用如下结构： On Error GoTo handle1 可能出现异常的代码块1 On Error GoTo handle2 可能出现异常的代码块2 ……