网站完全开放的特性，决定了网站比任何传统软件都更希望做到“系统看起来永远都是能够正常工作的”，所以采用正确的程序错误处理方式尤为重要。理论上来说，如果设计足够完美，开发人员足够谨慎，程序出现错误的可能为0.
但事实恰恰相反，复杂的业务逻辑，不同的硬件环境，或者不可信任的用户输入，都可能导致程序出错，服务当机。所以在稍微有点复杂的系统中，有个完善的错误机制是必须的。
在php5之前，因为缺乏对异常的支持。在做复杂的开发时，常常采取比较原始的“处理错误数值+记录log”的处理形式。
如：
function getResult($a,$b)
{
.......
if fatal error occur
return "error_type1";
.....
}
$result = getResult($a,$b);//理论上，getResult函数总能正确的返回$result
if($result=='error_type1')//但在一些特殊情况.$result无法正常取得
{
writeLog('result is empty!');//记录下log
die();//或者其他更“友好的”处理方式
}
理论上，通过“处理错误数值+记录log”的方式也可以达到我们的目标（事实上确实如此，在php3，php4的时候，已经出现了很多成功且足够复杂的系统，他们甚至考虑到所有的情况，因此不需要记录任何log）。但技术总要向前发展的，更何况，决大多数的开发人员并不具备牛人的严谨到滴水不漏的思维，所以我们还是不得不认真思考“如何处理程序错误”的问题。
上面的“错误处理+记录log”的方式，存在如下弊端：
1 如果错误情况太多，那相应的错误处理代码需要增加很多，这非常损害程序的可读性。你的程序看起来是“断断续续的”。
2 如果程序的逻辑很复杂（比如程序的函数调用非常复杂，如在 getResult2()函数 中调用 getResult() 的情况，甚至更复杂的多级嵌套的情况），那错误数值的传递处理会让你疲于奔命。因为为了确保错误能够得到有效的处理，你必须保证: 以无损耗的方式传递错误数值。
所以，改变这种原始的错误处理方式吧。引入异常处理机制，你会发现可喜的变化：
1 代码可读性大大增强。开发程序时逻辑思维变得很连贯，在“可疑的”地方，你只要抛出个异常就可以了。至于怎么处理，完全可以等到后面再去补充。当然，对于程序的读者，也不会觉得有被打断的感觉。
2 再也不需要考虑“错误数值如何无损耗的进行传递”这种费力又不怎么讨好的问题了。因为异常向上传递的特性，你的函数嵌套个2层，3层，再多层都没有问题。你只需要在外层有捕获异常的操作就可以了。
3 异常可以自由的定制，你可以按照功能对异常进行分类，更好的管理各种程序错误。同时对于你也可以更灵活的定制异常的处理方式。比如，在异常类里面实现记录log的功能等。
当然，是否使用异常要根据需求而定。php的一大特性就是部署快，如果是很小的项目，逻辑很简单，那使用一般的错误数值处理方式也许能够更快的部署。