本文面向的读者
本文面向希望了解PHP5异常处理机制的程序员。读者需要具有一定面向对象编程和PHP基础。
简介
本文集中讨论各种错误处理,在这里你将可以看到PHP4,PHP5中的多种错误处理方式。PHP5引入了“异常机制”――一个在对象体系中进行错误处理的新机制。就像你即将看到的,“异常”提供了不少比传统的错误处理机制先进的特性。
PHP5之前的错误处理
在PHP5之前的程序错误处理多使用以下三种办法:
1. 使用trigger_error()或die()函数来生成一个脚本层次的警告(warning)或致命错误(fatal error);
2. 在类方法或函数中返回一个错误标记(如false),也可能设置一个之后可以检查的属性或全局变量(如$error),然后在适合的地方检验其值再决定是否继续执行程序(如if($error==1){});
3. 使用PEAR处理错误;
(一)使用die()或trigger_error()
你可以使用die()函数来结束程序运行。以下是一个简单的类,它尝试从一个目录中加载一个类文件。
<? 代码列表 index.php ?> |
|
这是一个用PHP实现“Command Pattern设计模式”的简单例子(请参看《Java与模式》)。使用这个类的程序员(客户程序员client coder)可以将一个类放到目录中(例中为cmd_php4目录)。一旦文件和其中包含的类同名,并且这个类是Command类的子类,我们的类方法将生成一个可用的Command对象。Command类中定义了一个 execute()方法用来执行找到的命令,即
getCommandObject()
方法返回的对象将执行
execute()
.
我们再看看父类Command
类,我们将它存在
cmd_php4/Command.php文件中。
<? 代码列表cmd_php4/Command.php ?> |
|
你可以看到,Command
是
PHP4
中抽象类的实现,我们无法直接将其实例化,而必须先从中派生中子类然后再实例化。当我们使用
PHP5
后,我们可以使用更好的方式
—
使用
abstract
关键字将类和方法声明为“抽象”:
<? 代码列表 ?> |
|
下面是对上面的抽象类的实现,覆写了execute()方法,在其中加入真正可以执行的内容。这个类命名为realcommand
,可以在
cmd_php4/realcommand.php文件中找到。
<? 代码列表 cmd_php4/realcommand.php ?> |
|
使用这样的结构可以使代码变得很灵活。你可以在任何时候增加新的Command
类,而不需要改变外围的框架。但是你不得不注意一些潜在的中止脚本执行的因素。我们需要确保类文件存在,并且在文件中该类存在,并且该类是
Command
的子类
(
就像
realcommand
一样
)
。
在例子中,如果我们尝试寻找类的操作失败,脚本执行将会中止,这体现了代码的安全性。但这段代码不灵活,没有足够的弹性。极端的反映是类方法只能进行积极正面的操作,它只负责找出和实例化一个Command
对象。它无法处理更大范围内脚本执行的错误
(
当然它也不应该负责处理错误,如果我们给某个类方法加上太多与周边代码的关联,那么这个类的重用将会变得困难,不易扩展
)
。
尽管使用die()避免了在getCommandObject()
方法中嵌入脚本逻辑的危险,它对于对于错误的反应显得过于激烈
—-
马上中止程序。事实上有时候我们并不希望在找不到想要的类文件时就马上停止执行程序,也许我们有一个默认的命令让程序继续执行。
我们或许可以通过trigger_error()生成一个用户警告来代替,使程序更具有灵活性。
<? 代码列表 Index2.php ?> |
|
如果你使用trigger_error()
函数来替代
die()
,你的代码在处理错误上会更具优势,对于客户程序员来说更易于处理错误。
trigger_error()
接受一个错误信息和一个常量作为参数。常量为:
常量 | 含义 |
| A fatal error |
| A non-fatal error |
| A report that may not represent an error |
你可以设计一个错误处理器,然后再定义一个处理器选择函数set_error_handler()
来使用这个错误处理器。
<? 代码列表 Index2.php 后半段?> |
|
set_error_handler()
接受一个函数名作为参数。如果触发了一个错误,参数中的这个函数会被调用来处理错误。函数需要传入四个参数:错误标志,错误信息,出错文件,出错处的行数。你也可以将一组数组传递给
set_error_handler()
。数组中的第一个元素必须是错误处理器将调用的对象,第二个元素是错误处理函数的名称。
可以看出,我们的错误处理器相当简单简陋,还可以改进。然而尽管你可以在错误处理器添加某些功能,如记录出错信息,输出debug数据等,这仍然是一个过于粗糙的错误处理途径。你的选择仅限于已经考虑到的出错情况。例如捕捉一个E_USER_ERROR
错误,如果你愿意的话可以不中止脚本的执行
(
不使用
exit()
和
die())
,
但如果这样做的话,可能会引起一些很微妙的
bug
,本来应该中止的程序却继续执行了。
(二) 返回错误标记
脚本层次的错误处理比较粗糙但很有用。尽管如此,我们有时需要更大的灵活性。我们可以使用返回错误标识的办法来告诉客户代码“错误发生了!”。这将程序是否继续,如何继续的责任交给客户代码来决定。
这里我们改进了前面的例子来返回一个脚本执行出错的标志(false是一个常用的不错的选择)。
<? 代码列表 index3.php ?> |
|
这意味着你可以根据环境来处理多个错误,而不会在第一个错误发生时马上停止程序的执行。
<? 代码列表 ?> |
|
或者只是记录错误:
<? 代码列表 ?> |
|
使用像“false”这样的错误标志的好处是直观,但是明显给出的信息量不够,我们无法得知到底是在哪一个环节上错而导致返回false。你可以再设置一个error属性,这样在产生错误后输出出错信息。
<? 代码列表 index4.php?> |
|
这个简单的机制可以让setError()
记
录下错误信息。其它代码可以通过error()来获得脚本错误的相关信息。你应该将这个功能抽取出来并放在一个最基本的类中,其它所用类都从这个类继承而来。这样可以统一处理错误,否则可能出现混乱。我就曾经见过有些程序在不同的类中使用getErrorStr()
、
getError()
和error()
等功能相同的函数。
然而,实际开发中要让程序中的所有类都从同一个类中继承而来是很困难的,除非同时使用接口(interface)否则无法实现一些子类自身特有的功能,但那已经是PHP5的内容。就像我们将提到的,PHP5中提供了更好的解决方案。
(三)使用PEAR处理错误
你也可以使用PEAR来处理错误。当发生错误,将返回一个Pear_Error
对象。后面的代码通过一个静态方法
PEAR::isError()
来检验这个对象。如果错误确实发生了,那么返回的
Pear_Error
对象将提供你需要的所有相关信息:
这里我们修改了getCommandObject()
方法,使之返回一个
Pear_Error
对象。
<? 代码列表 index_pear.php?> |
|
Pear_Error
既是出错标志又包含有错误的相关具体信息,这对于客户代码来说是很好用的。
<? 代码列表 ?> |
|
尽管返回一个对象值可以让你灵活对程序中的问题作出反映,它也有“污染接口”的副作用。因为现在getCommandObject()
方法
的
出口有两个,而且都是对象,有时可能产生混淆。
PHP不允许你指明一个类方法或函数应当返回的值的类型,尽管这样比较方便。getCommandObject()
方法返回的即是
Command
对象或者一个
Pear_Error
对象。如果你想得到一定的类型的返回值,你必须每次都检验值的类型。一段谨慎的代码会充满复杂的检验条件语句,如果每种类型都检验的话。
以下是一段不考虑错误检验的PEAR::DB
客户代码
<? 代码列表 ?> |
|
程序的可读性很好,操作一目了然--我们选择一个数据库,新建一个数据表然后插入一行纪录,再取回数据,然后丢弃掉数据表。
再看看以下使用错误判断之后:
<? 代码列表 ?> |
|
很明显加上错误检验后,代码显得冗长复杂。其实以上代码比起实际项目中的代码还要简单一些,但已经足以说明错误检验的复杂程度。
综合以上的讨论,我们需要一个这样的错误处理机制:
- 允许方法给出一个出错标记给客户代码
- 提供程序错误的详细信息
- 让你同时判断多个出错条件,将你的错误报告和程序处理流程分开。
- 返回值必须是独立的类型,不会与正常返回的类型相混淆
PHP的异常机制恰好完全满足以上要求。
PHP5的异常机制
根据我们以上讨论的,PHP内建的异常类需要有以下成员方法:
可以看出来,Exception 类的结构和Pear_Error
很相似。
当你的脚本中遇到一个错误,你可以建立你的异常对象:
$ex = new Exception( "Could not open $this->file" );
Exception类的构造函数将接受一个出错信息和一个错误代码。
使用throw关键字
建立一个Exception对象后你可以将对象返回,但不应该这样使用,更好的方法是用throw关键字来代替。throw用来抛出异常:
throw new Exception( "my message", 44 );
throw 将脚本的执行中止,并使相关的Exception对象对客户代码可用。
以下是改进过的getCommandObject()
方法
:
(
见下页代码列表
)
。
代码中我们使用了PHP5的反射(Reflection)API来判断所给的类是否是属于Command
类型。在错误的路径下执行本脚本将会报出这样的错误:
Fatal error: Uncaught exception 'Exception' with message 'Cannot find command/xrealcommand.php' in /home/xyz/BasicException.php:10
Stack trace:
#0 /home/xyz/BasicException.php(26):
CommandManager->getCommandObject('xrealcommand')
#1 {main}
thrown in /home/xyz/BasicException.php on line 10
默认地,抛出异常导致一个fatal error。这意味着使用异常的类内建有安全机制。而仅仅使用一个错误标记,不能拥有这样的功能。处理错误标记失败只会你的脚本使用错误的值来继续执行。
Try-catch 语句
<? 代码列表 index_php5.php?> |
|
为了进一步处理异常,我们需要使用try-catch语句—包括Try语句和至少一个的catch语句。任何调用 可能抛出异常的方法的代码都应该使用try语句。Catch语句用来处理可能抛出的异常。以下显示了我们处理getCommandObject()
抛出的异常的方法:
<? 代码列表 index_php5.php 后半段?> |
|
可以看到,通过结合使用throw关键字和try-catch语句,我们可以避免错误标记“污染”类方法返回的值。因为“异常”本身就是一种与其它任何对象不同的PHP内建的类型,不会产生混淆。
如果抛出了一个异常,try语句中的脚本将会停止执行,然后马上转向执行catch语句中的脚本。
如果异常抛出了却没有被捕捉到,就会产生一个fatal error。
处理多个错误
在目前为止异常处理看起来和我们传统的作法—检验返回的错误标识或对象的值没有什么太大区别。让我们将CommandManager
处理地更谨慎,并在构造函数中检查
command目录是否存在。
<? 代码列表 index_php5_2.php?> |
|
这里有两个地方的调用可能导致程序出错(__construct()
和
getCommandObject()
)
。尽管如此,我们不需要调整我们的客户代码。你可以在try语句中增添众多内容,然后在catch中统一处理。如果CommandManager
对象的构造函数抛出一个异常,则
try
语句中的执行中止,然后
catch
语句被调用捕捉相关的异常。同样地,
getCommandObject()
也是如此。这样,我们有同时存在两个潜在的引发错误的地方,和一个唯一的语句来处理所有的错误。这让我们的代码看起来更加整洁,又可以满足错误处理的要求。和前面提到的
PHP
的传统的错误方法相比,显然很有优势。
注意:尽管和
index_php5.php
相比,前半段代码有两个
(
多了一个
)
可能出错的地方,这段代码和
index_php5.php
的后半段完全相同。
<? 代码列表 index_php5_2.php 后半段?> |
|
还有一个地方我们没有提到。我们怎样区分不同类型的错误?例如,我们可能希望用一种方法来处理找不到目录的错误,而用另一种方法来处理非法的command类。
Exception类可以接受一个可选的整型的错误标识,这是在catch语句中区分不同错误类型的一个方法。
<? 代码列表 index_php5_3.php?> |
|
通过传递 CMDMAN_ILLEGALCLASS_ERROR
和
CMDMAN_GENERAL_ERROR
其中之一的参数给我们抛出的异常对象,我们就可以让客户代码区分不同类型的错误,并定义不同的处理策略。
<? 代码列表 index_php5_3.php?> |
|
我们也可以用另一种方法来实现这样的效果—从最根本的Exception类中派生出代表不同类型异常的子类,再抛出和捕捉。
Exception类的子类
有两个理由让我们想要从Exception类中派生中子类:
1. 让子类提供自定义的功能;
2. 区分不同类型的异常;
看第二个例子。使用CommandManager
类时
我们可能会产生两个错误:一个是一般性的错误如找不到目录,另一个是找不到或无法生成Command
对象。
这样我们需要针对这两个错误来定义两种异常子类型。
<? 代码列表 index_php5_4.php?> |
|
当我们的类不能找到正确的command目录时,将抛出一个CommandManagerException
异常;当在生成
Command
对象时产生错误,则
getCommandObject()
方法将抛出一个
IllegalCommandException
异常。注意存在多个可能导致抛出
IllegalCommandException
异常的原因
(
如未找到文件,或在文件中未找到正确的类
)
。我们将前两个例子结合起来并为
IllegalCommandException
提供整型的错误标识常量来代表不同类型的出错原因。
现在CommandManager
类已经具备了处理这多种出错情况的能力,我们可以增加新的
catch
语句来匹配不同的错误类型。
<? 代码列表 index_php5_4.php 后半段?> |
|
如果CommandManager
对象抛出一个
CommandManagerException
异常,则相对应的
catch
语句将会执行。每个
catch
语句的参数就像是一个匹配测试一样,第一个发生匹配的
catch
语句将会执行,而不执行其它的
catch
语句。所以,你应当将针对特定异常的
catch
语句写在前面,而将针对一般性的异常的
catch
语句写在后面。
如果
你将
catch
语句这样写:
<? 代码列表 ?> |
|
那么当异常抛出时,不管是什么异常第一个catch语句catch (
Exception $e
){}
将总是被执行。这是由于任何异常都从属于
Exception
类型,所以总是匹配。这就达不到我们所要的针对特定异常进行不同处理的目的。
如果你在捕捉特定类型的异常,那么在最后一个catch语句中捕捉Exception类型的异常是一个好主意。最后一个catch语句表示catch-all,捕捉所有异常。当然,你可能不想马上处理异常,而是想要将它传递,然后在适当的时候处理。这是PHP的异常机制中另一个需要讨论的地方。
异常的传递、重掷异常
如果我们已经触发了一些在发生时无法马上处理的异常,有一个很好的解决方案—将处理异常的责任交回给调用当前方法的代码,也就是在catch语句中再次抛出异常(重掷异常)。这将使异常沿着方法的调用链向上传递。
<? 代码列表 index_php5_5.php?> |
|
以上我们使用了RequestHelper
类中的
一段客户代码。RequestHelper
用来处理用户提供的请求数据。在构造函数中我们接受一个用来
debug
的数组。如果没有接受到这个数组,类将使用
$_REQUEST
数组。无论哪个数组被使用,它都将分配给名为
$request
的变量。客户代码通过给出一个
request
数组的
cmd
元素,告知它想要执行的
command
。
getCommandString()
方法则测试一个名为
$cmdstr
的属性。如果它是空的,则方法将$request中的cmd元素的内容分配给$cmdstr,并返回值。如果不是空的,方法直接返回$cmdstr属性的值。通过这样的机制,command字符串可以在RequestHelper
类中被覆写。
在最后我们将除
IllegalCommandException
外的所有异常对象都将交给更高一级的类来延后处理。我们在最后一个
catch
语句中再次抛出异常。
|
如果我们捕捉到一个llegalCommandException 异常,我们首先尝试去调用 一个默认的command。我们通过将$cmdstr属性设置为与$defaultcmd等值,并重复地调用runCommand方法。如果$cmdstr和$defaultcmd字符串已经相等,我们没有什么需要做的,则重掷异常。
事实上在 Zend引擎II将会自动重掷所有未匹配的异常,所以我们可以省略最后一个catch语句。这是CommandManager::getCommandObject()的最后一行:
return $class->newInstance();
这里要注意两个问题:
首先,我们假设CommandManager类的构造函数不需要参数。在本文中我们不讨论需要参数的情况。
其次,我们假设command类(这里是指我们自定义的realcommand)可以被实例化。如果构造函数被声明为private,这个语句将抛出一个ReflectionException对象。如果我们没有在RequestHelper中处理异常,则这个异常将被传递到调用RequestHelper的代码中。如果一个异常被隐性地抛出,你最好在文档中说明一下,或者手动地抛出这个异常--这样其他的程序员使用你的代码时容易处理可能发生的异常情况。
获得异常相关的更多信息
以下是用来格式化输出异常信息的代码:
<? 代码列表 index_php5_6.php?> |
|
如果你的realcommand类无法被实例化(例如你将它的构造函数声明为private)并运行以上代码,你可以得到这样的输出:
ReflectionException
Access to non-public constructor of class realcommand (0)
file: c:/MyWEB/Apache/htdocs/php5exception/index_php5_4.php
line: 31
#0 :/MyWEB/Apache/htdocs/php5exception/index_php5_5.php(25): CommandManager->getCommandObject()
#1 :/MyWEB/Apache/htdocs/php5exception/index_php5_6.php(10): RequestHelper->runCommand('realcommand')
#2 :/MyWEB/Apache/htdocs/php5exception/index_php5_6.php(23): Front::main()
#3 {main}
你可以看到getFile()和getLine()分别返回发生异常的文件和行数。GetStackAsString()方法返回每一层导致异常发生的方法调用的细节。从#0一直到#4,我们可以清楚地看到异常传递的路线。
你也可以使用getTrace()方法来得到这些信息,getTrace()返回一个多维数组。第一个元素包含有异常发生的位置,第二个元素包含外部方法调用的细节,直到最高一层的调用。这个数组的每个元素本身也是一个数组,包含有以下几个键名(key):
key | 含义 |
| 产生异常的文件 |
| 产生异常的类方法所在行数 |
| 产生异常的函数/方法 |
| 调用的方法所在类 |
| 调用类型:'::' 表示调用静态类成员 |
| 类方法接受的参数 |
总结
异常机制提供了几个非常关键的好处:
(1) 通过将错误处理集中于catch语句中,你可以将错误处理从应用流程中独立出来。这也使代码的可读性提高,看起来令人愉快。我通常采取非常严格的策略来捕捉所有异常并中止脚本执行。这样可以获得所需的附加的弹性,同时实现安全易用的异常管理。
(2) 重掷异常,将异常数据流从低层传递至高层,就是说异常被传回最适合决定如何处理异常的地方。这看起来会显得有点奇怪,但实际情况中很经常我们在异常发生的时候无法立刻决定如何处理它。
(3) 异常机制提供的Throw/catch避免了直接返回错误标识,方法的返回值是可以由你的类来决定的。其它程序员使用你的代码时,可以指定返回一个他希望的形式,而不需要令人疲倦的不停地测试。
关于作者
Matt Zandstra是一个作家,同时也从事服务器端编程和培训方面的技术顾问工作。他和他的搭档Max Guglielmino一起运营Corrrosive—-一个提供开放源代码、开发标准方面培训、策划、开发的技术公司。
Matt同时也是SAMS《Teach Yourself PHP in 24 Hours》一书的作者。他现在正在写一本有关PHP中的面向对象编程的书籍。
| Haohappy Email: Haohappy@msn.com Blog: blog.csdn.net/haohappy2004 |
http://www.openphp.cn/index.php?module=article&id=2