我最近刚刚读到一篇关于http://phpmaster.com/exceptional-exceptions/他谈到了例外情况：
您的呼叫代码永远不应该读取该消息。这个消息唯一有好处的是对开发人员来说。
在W3Schools网站上，他们展示了一个例子，当异常消息被捕获时，他们会输出异常消息，所以我很困惑。我从中学到了很多http://www.phpmaster.com相信他们所说的，但W3Schools也总是可靠的，那么该怎么做才是正确的呢？
异常消息是应该输出给用户的，还是只是为开发人员准备的？也许它甚至没有那么重要，而且它可以双向使用而不会造成任何伤害？
这取决于场景，但最大的问题是安全性。当开发人员抛出异常时，他们通常会尝试在消息中包含一些关于到底出了什么问题的有用信息。他们不知道在目前的情况下，这些信息是否会被你认为是敏感的。
举个例子，假设你有一个有登录表单的网站。如果数据库中的Users表丢失，并且有人试图登录，则抛出的异常可能是类似Unable to find table users in database MyDb (db.mysite.com) 的异常
如果该消息显示给恶意用户，他们现在就知道你的数据库在哪里，数据库/表的名称是什么。
在这种情况下，我倾向于用一个唯一的Id记录完整的异常，并将Id显示给用户，以便他们稍后在需要时跟进我。
相反，如果它是一个桌面应用程序，那么我倾向于另一种方式——异常消息可以帮助最终用户(例如，Access Denied是用户可能能够解决的问题(。即便如此，您也不确定异常消息是否有用(如Reference not set to an instance of an object(，所以我倾向于将任何异常封装在更有用的异常中(如Unable to connect to database(，并公开所有内部异常的列表。这意味着用户可以得到一条可以理解的消息，但如果可用，也可能得到更有用的信息，而不是安全风险
没有明确的答案。这取决于消息提供的信息
如果您的邮件没有提供任何敏感信息，您可以将其打印给客户端。
我喜欢使用$code参数将错误打印到客户端
类似的东西：
function clientError(Exception $e) {
$error = 'Unknown error!';
switch ($e->getCode()) {
case 404:
$error = 'Not found error!';
break;
case 403:
$error = 'You cannot access this page!';
break;
...
...
}
return "$error [error code: {$e->getCode()}]";
}
将错误消息保存在错误日志中，并将clientError打印到客户端：
try {
if (!$user->isMember()) {
throw new Exception("Guest {$user->id} tried to access to newPost.php page", 403);
}
}
catch (Exception $e) {
$errorLog->newError($e);
echo clientError($e);
}
此示例应在错误日志中添加一行，并显示以下消息：
"Guest 123尝试访问newPost.php页面">
并打印：
"您无法访问此页面！">
几乎正确。你当然不想给一个黑客类型，比如Stackframe。向用户展示它们也没那么有用。话虽如此，遵循这一建议会落入陷阱。
有时，您得到的异常类过于通用，识别它的唯一方法是测试文本。OLE在这方面堪称经典。不管怎样，运行一条sql语句都会得到OLEDB异常。另一个相关的问题是，当你尝试catch-end，并假设唯一会抛出的异常是你认为可能出现的异常时，然后你会收到一个用户打来的电话，说我收到了"保存你的文档有问题"，这可能是一大堆问题中的任何一个。
不管你做了什么，如果你得到了原始异常和堆栈帧，都会记录下来。这是显而易见的，但太多人落入了这个陷阱。
不要把问题简化到你所传达的信息完全无用的地步。
即使是开发人员的例外情况也表明，0000000的访问违规0000000是一个好的路由，"未知ole错误(5("是非常愚蠢的，或者一直令人讨厌的msi一个"错误1603"。
关于W3学校：http://w3fools.com/
例外情况仅适用于开发人员。它们可能包含有助于攻击者入侵你的网站的信息，而且它们并不漂亮。如果您预期会发生异常，则捕获该异常，并执行用户预期的操作，例如显示他们能够理解的错误消息。如果你没想到会发生异常，那么你就有了一个需要解决的问题。
未捕获的异常也称为"错误"；(
大多数异常对最终用户没有帮助，因为他们缺乏编程经验，您应该处理自己的异常，并向最终用户发出明确的消息