PHP 错误处理:die() Vs trigger_error() Vs throw Exception
关于 PHP 中的错误处理——据我所知有 3 种样式:
In regards to Error handling in PHP -- As far I know there are 3 styles:
die()
或exit()
样式:
$con = mysql_connect("localhost","root","password");
if (!$con) {
die('Could not connect: ' . mysql_error());
}
抛出异常
样式:
if (!function_exists('curl_init')) {
throw new Exception('need the CURL PHP extension.
Recomplie PHP with curl');
}
trigger_error()
样式:
if(!is_array($config) && isset($config)) {
trigger_error('Error: config is not an array or is not set', E_USER_ERROR);
}
现在,在 PHP 手册中,所有三种方法都使用了.
Now, in the PHP manual all three methods are used.
我想知道我应该更喜欢哪种风格&为什么?
What I want to know is which style should I prefer & why?
这 3 种是相互替代吗?因此可以互换使用吗?
Are these 3 drop in replacements of each other & therefore can be used interchangeably?
有点 OT:是我还是所有人都认为 PHP 错误处理选项太多以至于让 php 开发人员感到困惑?
Slightly OT: Is it just me or everyone thinks PHP error handling options are just too many to the extent it confuses php developers?
推荐答案
第一个不应该在生产代码中使用,因为它传输与最终用户无关的信息(用户无法对 做任何事情"无法连接到数据库").
The first one should never be used in production code, since it's transporting information irrelevant to end-users (a user can't do anything about "Cannot connect to database").
如果您知道在某个关键代码点,您的应用程序可能会失败,并且您希望您的代码在多个调用级别之间恢复,那么您就会抛出异常.
You throw Exceptions if you know that at a certain critical code point, your application can fail and you want your code to recover across multiple call-levels.
trigger_error()
可让您细粒度的错误报告(通过使用不同级别的错误消息)并且您可以对最终用户隐藏这些错误(使用 set_error_handler()
) 但在测试过程中仍然显示给你.
trigger_error()
lets you fine-grain error reporting (by using different levels of error messages) and you can hide those errors from end-users (using set_error_handler()
) but still have them be displayed to you during testing.
此外,trigger_error()
可以生成在开发过程中很重要的非致命消息,可以使用自定义错误处理程序在生产代码中抑制这些消息.您也可以产生致命错误 (E_USER_ERROR
),但这些错误是不可恢复的.如果您触发其中之一,程序执行将在该点停止.这就是为什么,对于致命错误,应该使用异常.这样,您就可以更好地控制程序的流程:
Also trigger_error()
can produce non-fatal messages important during development that can be suppressed in production code using a custom error handler. You can produce fatal errors, too (E_USER_ERROR
) but those aren't recoverable. If you trigger one of those, program execution stops at that point. This is why, for fatal errors, Exceptions should be used. This way, you'll have more control over your program's flow:
// Example (pseudo-code for db queries):
$db->query('START TRANSACTION');
try {
while ($row = gather_data()) {
$db->query('INSERT INTO `table` (`foo`,`bar`) VALUES(?,?)', ...);
}
$db->query('COMMIT');
} catch(Exception $e) {
$db->query('ROLLBACK');
}
在这里,如果 gather_data()
只是简单的嘶嘶声(使用 E_USER_ERROR
或 die()
),则有机会,之前的 INSERT
语句会将其添加到您的数据库中,即使不需要,您也无法控制接下来会发生什么.
Here, if gather_data()
just plain croaked (using E_USER_ERROR
or die()
) there's a chance, previous INSERT
statements would have made it into your database, even if not desired and you'd have no control over what's to happen next.
相关文章