检测mysqli准备语句中的错误 | 检测mysqli准备语句中的错误

本文介绍了检测mysqli准备语句中的错误的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我有一个自定义的错误处理程序，但我需要知道在哪里测试我准备的语句中的错误。

我是否一直测试 prepare（）， bind（）， execute（）和 store_result（）阶段或刚刚选择的阶段？

  $ statement = $ databaseHandler-> ; mysqli-> prepare（$ query）或trigger_error（$ mysqli-> error）; 
 $ statement-> bind_param（'s'，$ userIp）或trigger_error（$ mysqli->错误）; 
 $ statement-> execute（）或trigger_error（$ mysqli-> error）; 
 $ statement-> store_result（）或trigger_error（$ mysqli-> error）;

我要查找 num_rows 或者只是php没有做一个基本的工作，因为它不再与mysqli服务器通信，所以没有什么应该出错？

你有什么意义应该停止寻找错误，是否在 execute（）之后？因为 store_result（）不工作将是PHP失败的工作，这将是服务器实际上不起作用？

另外我看到代码，其中 prepare（） stage只是围绕在一个if语句中的错误，这样做是否意味着其他阶段的错误不会被处理准备阶段最有可能出错吗？

解决方案

AFAIK，您需要将mysqli错误转换为PHP错误，仅适用于准备和执行 - 与服务器交互的命令。所有其他命令都将发出正常的PHP错误。

虽然有另一种方法，但它是相当新的，我没有测试太多。但这是非常诱人的，因为它会让你摆脱所有这些触发错误：

  mysqli_report（MYSQLI_REPORT_ERROR）;

这个简单的调用将使mysqli自动发出PHP错误。

虽然它 MYSQLI_REPORT_STRICT 似乎更好的选择，但它不适用于我的版本。虽然 MYSQLI_REPORT_ALL 也可以翻译mysqli提示，一方面，这是非常好的，但它可以通过像的通知垃圾邮件'没有使用索引在查询/准备语句'中，这是坏的。因此，目前唯一可用的设置是 MYSQLI_REPORT_ERROR

所以，你可以使它只是

  mysqli_report（MYSQLI_REPORT_ERROR）; 
 
 $ statement = $ db-> prepare（$ query）; 
 $ statement-> bind_param（'s'，$ userIp）; 
 $ statement-> execute（）; 
 $ statement-> store_result（）;

更新

MYSQLI_REPORT_STRICT ：

  mysqli_report（MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT）;

将使mysqli抛出异常而不是常规错误。

异常优于常规错误在许多方面：它们总是包含一个堆栈跟踪，它们可以使用 try..catch 或使用专门的错误处理程序处理。甚至未经处理，它们作为常规的PHP错误提供所有重要信息，遵循站点范围的错误报告设置。

I have a custom error handler in place but I need to know where to test for errors within my prepared statement.

Do I test at all prepared() , bind(), execute() and store_result() stages or just selected stages?

$statement = $databaseHandler->mysqli->prepare($query) or trigger_error($mysqli->error);
$statement->bind_param('s', $userIp) or trigger_error($mysqli->error);
$statement->execute() or trigger_error($mysqli->error);
$statement->store_result() or trigger_error($mysqli->error);

Do i even have to check for errors when looking for num_rows or would that just be php failing to do a basic job as its no longer communicating with the mysqli server so nothing should go wrong?

What's the point you should stop looking for errors, is it after execute()? as store_result() not working would be php failing to do its job, which would be the server not actually functioning?

Also I have seen code where the prepare() stage is just surrounded in an if statement for errors, by doing this does this mean an error in the other stages would not be handled? Is the prepared stage most likely to go wrong the most?

解决方案

AFAIK, you need to convert mysqli errors into PHP errors only for prepare and execute - commands interacting with server. All other commands will emit regular PHP errors already.

There is another method though, but it is quite new and I haven't tested it much. But it is quite tempting, as it will let you get rid of all these trigger errors:

mysqli_report(MYSQLI_REPORT_ERROR);

this simple call will make mysqli emit PHP errors automatically.

Although it MYSQLI_REPORT_STRICT seems better choice, but it doesn't work for my version yet. While MYSQLI_REPORT_ALL would translate mysqli hints as well, which is, on one hand, quite good, but it can spam you with notices like 'No index used in query/prepared statement', which is bad. Thus, the only usable setting at the moment is MYSQLI_REPORT_ERROR

So, you can make it just

mysqli_report(MYSQLI_REPORT_ERROR);

$statement = $db->prepare($query);
$statement->bind_param('s', $userIp);
$statement->execute();
$statement->store_result();

Update

Finally, I've got the proper usage of MYSQLI_REPORT_STRICT:

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

Will make mysqli throw exceptions instead of regular errors.
Exceptions are better than regular errors in many ways: they always contains a stack trace, they can be caught using try..catch or handled using dedicated error handler. And even unhandled, they act as regular PHP errors providing all the important information, following site-wide error reporting settings.