大多数最近被实现的PHP扩展都拥有OO（面向对象）接口. 因此，这些API倾向于抛出异常，而不是发生错误终止。PHP中能够抛出异常的扩展，稍微列举出几个就包括有PDO, DOM, Mysqli, Phar, Soap 以及 SQLite.
新特性：新核心异常类型在PHP 5.3开发中，我们展示了一些有趣的新异常类型。这些异常在PHP 5.2.x中已经存在，但最近还没到“重新评估”异常的最佳实践，现在他们会显得更加引人注目。他们在SPL扩展中得以应用，并在手册中列出（这里）由于这些新的异常类型是PHP核心的一部分，也是SPL的一部分，它们可以被任何用PHP 5.3（及以上）运行代码的人使用。虽然在编写应用程序层的代码时，看起来不那么重要，但在我们写或者使用代码库时，使用这些新异常类型变得更加重要
那么为什么新异常是普通类型？以前，开发者试图通过在异常消息提醒中放入更多的内容来赋予异常更多的含义。虽然这样做是可行的，但是它有几个缺点。一是你无法捕获基于消息的异常。这可是一个问题，如果你知道一组代码是同样的异常类型与不同的提示消息对应不同异常情况下，处理起来的难度将相当的大。例如，一个认证类，在对$auth->authenticate();；它抛出异常的相同类型的（假设是异常），但不同的消息对应两个具体的故障：产生故障原因是认证服务器不能达到但是相同的异常类型却提示失败的验证消息不同。在这种情况下（注意，使用异常可能不是处理认证响应最好的方式），这将需要用字符串来解析消息从而处理这两种不同的情况。
这个问题的解决办法显然是通过某种方式对异常进行编码，这样就可以在需要辨别如何对这种异常环境做出反应的时候能够更加容易的查询到。第一个反应库是使用异常基类的$code属性。另一个是通过创建可以被抛出且能描述自身行为的子类或者新的异常类。这两种方法具有相同的明显的缺点。两者都没有呈现出想这样的最好的例子。两者都不被认为是一个标准，因此每个试图复制这两种解决方案的项目都会有小的变化，这就迫使使用这需要回到文档以了解所创建的库中已经有的具体解决方案。现在通过使用SPL的新的类型方法，也称作php标准库；开发者就可以以同样的方式在他们的项目中，并且复用这些项目的新的最佳的方法已经出现。
第二个缺点是使用详细信息的做法使得理解这些异常情况对那些非英语或英语能力有限的开发者来说十分困难。这可能会使的开发者在试图理解异常信息的含义的过程十分的缓慢。许多开发者也会写关于异常的文章，因为还未出现一个统一的整合过的标准所要有同这些开发者数量相同的不同的版本来描述异常消息所描述的情况。
所以我如何去使用它们，就用这些让人无语的密密麻麻的细节描述？
现在在SPL中有总共13个新的异常类型。其中两个可被视为基类：逻辑异常和运行时异常;两种都继承php异常类。其余的方法在逻辑上可以被拆分为3组：动态调用组，逻辑组和运行时组。
动态调用组包含异常 BadFunctionCallException和BadMethodCallException，BadMethodCallException是BadFunctionCallException（LogicException的子类）的子类，这意味着这些异常可以被其直接类型（译者注：就是异常自身的类型，大家都知道异常有很多种）、LogicException，或者Exception抓到（译者注：就是catch）你应该在什么时候使用这些？通常，你应该在由一个无法处理的__call()方法产生的情况，或者回调无法不是一个有效的函数（简单说，当某些东西并非is_callable()）时使用。
例如：
// OO variant
class Foo
{
public function __call($method, $args)
{
switch ($method) {
case 'doBar': /* ... */ break;
default:
throw new BadMethodCallException('Method ' . $method . ' is not callable by this object');
}
}
}
// procedural variant
function foo($bar, $baz) {
$func = 'do' . $baz;
if (!is_callable($func)) {
throw new BadFunctionCallException('Function ' . $func . ' is not callable');
}
}
一个直接的例子，在__call时call_user_func()。这组异常在开发各种API动态方法的调用、函数调用时非常有用，例如这是一个可以被SOAP和XML-RPC客户端/服务端能够发送和解释的请求。