为什么MySQLi中的例外PHP

Question

我听说你应该在使用mysqli而不是mysql（i）错误代码处理PHP代码时使用异常。

于是，我开始做了应该把所有的错误代码根据错误信息来自己的异常的mysqli对象的自己的包装。关于大量的可能的错误代码和你必须用自己的方法覆盖所有mysqli方法的事实，我开始怀疑它是否真的有必要。

在大多数情况下，捕获大多数常见错误代码并提供最常用函数的小封装就足够了，但它并不完整，也不是非常安全（即，当您没有捕获到某些错误代码时， ）。

并用if/else和mysqli_connect_errno（或者像那样）处理错误代码与使用 ...处理它们非常相似。

那么，为什么是它有用包的mysqli对象转换成自己的数据库对象翻译错误代码为例外？

你的， GREENY所有的

Answer 1

首先，这是在现代MVC开发结构的最佳实践原则和基本。

一些优势，这将给予你的是，你的开发团队将花费更少的时间调试，因为你在你的包中定义的异常将更加细致和明确一些故障比标准MySQL错误会给。

其次（你实际上已经自己说的），例外可以被捕获，误差不能，这意味着你的发展的另一个生产率的提高。

Answer 2

为什么PHP例外的MySQLi

是一个问题。

为什么它来包装的mysqli对象到自己的数据库对象翻译错误代码为例外有用吗？

是另一个

为什么是有用的包装mysqli的对象到自己的数据库对象

又是一个不同的。

把所有的错误代码根据错误信息来自己的异常。

实际上是唯一真正的问题。

把它们混在一起，你永远得不到满意的答案。

你首先必须了解的 - 没有自给自足的目标。每一个行动都必须采取，不是因为“有人这么说”，而是因为你需要它。如果你不需要它 - 最好不要管它。

因此它适用于特定的例外。只有在您有特定场景需要处理时才需要。说，你想赶上“重复键”的错误。因为你有一些代码可以运行。如果是这样 - 那么继续DuplicateKeyException。意味着你总是可以在try..catch中包装数据库操作并捕获这个非常特殊的异常。虽然所有其他例外将不会被捕获和冒泡。这种方法的一个明显的优势 - 你总是知道你需要创建哪些例外。

但是，如果您没有其他情况，只记录一个错误 - 那么您根本不需要特定的例外。这使得你的任务变得更加简单。仅仅因为mysqli能够自行抛出异常 - 所以，你不需要抛出任何特定的异常，也不需要捕捉它。