【发布时间】：2012-06-30 05:26:14
【问题描述】：
我收到了不同的信号。 PDO documentation 中的警告似乎很清楚，省略 try-catch 可能会危及安全性。但是，this thread 表明这并不是必需的。在我看来，将每个查询包装在 try-catch 中会很烦人。有关如何处理此问题的任何建议？
【问题讨论】：
【发布时间】：2012-06-30 05:26:14
【问题描述】：
存在安全风险，但您无需到处添加 try/catch。风险在于，如果您没有捕获异常，则异常的错误消息（可能包含敏感信息）可能会显示给用户。
但正如文档所述，您可以改为添加exception handler。通过重定向到通用错误消息，您可以避免向用户显示错误消息中的敏感信息。
在任何情况下，设置一个通用的错误处理程序似乎都是一件非常明智的事情。您不想向用户显示神秘的错误消息。即使您确实采用“尝试/捕获所有内容”的方法，也很难 100% 确定您已捕获所有可能发生的异常，因此异常处理程序仍应用作后备。
【讨论】：
-
感谢大家的回答！很难只选择一个，但马克是第一个，他的建议很中肯。
-
还有一个问题要问你。我是在每个页面上使用 set_exception_handler 方法还是每个会话只使用一次？
-
@danielfaraday：每次会话一次。
-
@LiorCohen afaik 你必须为每个请求调用 set_exception_handler，该设置不可能在请求之间持续存在。
-
@Mahn：这就是我的意思......显然程序的易失状态不会在请求之间持续存在。我的假设是研究 PDO 和异常的人已经知道 PHP ;-)
PDO 有three configurable error modes。默认只是设置错误码，不抛出异常。
但是，您应该使用PDO::ERRMODE_EXCEPTION。 PHP 和 PDO 通常处理错误的方式（即默默地继续编写代码并在不告诉你的情况下做错事）绝对是疯狂的，也是 PHP 可怕的一个重要原因。
如果您的查询出现问题，正确的做法是停止执行并引发异常，这样您就有了清晰的回溯，可以找到并解决问题。
另外，使用 try-catch 比在每次查询后检查 errorCode 和 errorInfo 更容易（即，不那么“烦人”）。如果您预期错误的可能性并且可以对此采取一些措施，您应该只使用 try-catch - 否则您应该让异常冒泡。如果它是一个意外错误，它可能来自您的代码中的错误，您应该通过异常了解它，以便您可以修复它！
如果您想在报告异常方面做一些特别的事情（例如，漂亮地打印它，给您发送电子邮件等等），然后注册 default exception handler 以处理任何未捕获的异常。在生产系统上，您应该注册一个默认的异常处理程序，该处理程序显示一个通用的 500 页面并显示错误详细信息，并在其他地方记录完整的回溯以进行调试。
【讨论】：
如果错误可能发生，那么它最终会。无论您运行的环境如何，您都需要处理 PDO 查询可能生成的任何潜在错误。假设（正如您发布的线程中的人所做的那样）因为这是一个生产系统，所以不需要 try..catch 是愚蠢的，恕我直言。错误不仅会在您调试代码时引发，而且也可能发生在生产系统上。就我个人而言，我喜欢围绕我在日志中看到的错误了解上下文，所以我确实使用 try..catch 来处理我的查询。
这也与您最终呈现给用户的错误无关。我发现在这种情况下使用安全这个词会使事情变得模糊。无论您如何处理错误（这不是 PDO 特定的），您的系统都不应向用户显示神秘的错误消息（可能包括敏感数据）。
有几种方法可以解决这个问题：
- 创建一个函数来为您执行 PDO 查询，方法是传递一个已绑定所有内容的准备好的语句。
- 创建一个全局异常处理程序并在那里捕获任何异常（我不喜欢这种方法，因为您最终会丢失上下文...如果它被某个全局处理程序捕获，我会向用户显示什么错误？您如何回溯如果它是在某些全局上下文中被捕获的，是否会出现这样的错误？）。
- Initialize PDO 不要抛出异常并进行手动错误检查，如果那是你的毒药。就我个人而言，我发现异常更适合基于 OOP 的系统，但每个人都有自己的情况。
我的 2c。
【讨论】：
-
谢谢 Lior。伟大的洞察力。 +1