Prepared statements...custom errors

PHP
1

This is the code for a prepared statement I am using:

  if ($stmt = $connection->prepare('INSERT into appointments (Bookfrom,startDate,endDate,apps_origin,staffID,bookedfor) VALUES( ?, ?, ?, ?, ?, ? )'))
    {
         
        $stmt->bind_param('siisii',$name,$start,$end,$origin,$staf,$bookedfor);
         $stmt->execute();
         if($stmt->errno!==0)
         {
             printf("Error-execution failed : %s.\n", $stmt->error);
          return  false;
         }
         $stmt->close();
    }
    else
    {printf("Error-prepare statement failed: %s.\n", $connection->error);
     return  false;
    }

The above code though(when failing) will output error messages produced by PHP…
I want to create custom errors though…so 2 questions arise:

  1. I intend using an error suppression operator though to silence PHP errors…in the above code **where should I use it?
  2. Nonetheless…errors produced by PHP are useful…is there a way “getting” them either way so I can store them in a log-for example?
2

I would not suppress errors.

But I wouldn’t display them past the development stage either.

You can have them sent to a log file or email instead

http://php.net/manual/en/function.error-log.php

3

well…I have the following problem:
I am using backbone to handle js code…and one of its function handles the response from the server.
I want to perform some action based on this response…but when a prepared statement fails and for example I get this warning:

<b>Warning</b>:  mysqli_stmt::bind_param(): Number of elements in type definition string doesn't match number of bind variables in <b>C:\Apache24\htdocs\Appointments\Administrator\admin_db_code.php</b> on line <b>246</b><br />

I cannot check for the above warning…the server does return the above but it is useless in the client.

Normally I use json_encode but in this case it will do nothing.

What can I do?

4

it seems the solution lies in turning off errors is production environment

5

Yes. Send them to a log file (as linked to previously) instead

6

Ok then…there is one little detail that must be addressed…take a look at this code:

if($stmt->errno!==0)
         { 
             printf("Error-execution failed : %s.\n", $stmt->error);
          return  false;

Since I will send the error in a log,I will not print it to the browser.
I have no idea how logging works…how I could send the above error related to stmt in a log.
I know this is a huge topic, I would appreciate though if you could help a little

7

Do you have the code inside try - catch ?

eg. this is from one of my current dev scripts

	try {
// database code
	}
	catch(PDOException $e) {
		print 'Exception : '.$e->getMessage();
	}

If this were production, I would have error_log instead of the print

8

PDOException does not work on MySQLi. you’d need 1) set MySQLi to use exceptions (hint: see mysqli_driver) 2) catch a mysqli_sql_exception or RuntimeException

9 
$errorLogFile = '/var/tmp/my-errors.log';

if($stmt->errno!==0)
{	
	// Log error to file at location defined by $errorLogFile
	$errorMessage = 'Error-execution failed : ' . $stmt->error . '\n';
	error_log($errorMessage, 3, $errorLogFile);
}
10

Yes I agree…this is what I had in my mind. I have one question though…

Where does the try…catch block fit in all this…it is something I have not understand yet.

In my case:

  1. I create a function with database code(prepared statement) in it-that outputs true or false.
  2. Then the function is called at a script and its output values checked

In the above scheme where does the try…catch block fit?Is it necessary?

11

it only fits if your connection actually uses exceptions for error handling, which you have to set up for PDO/mysqli explicitly.

it fits around the complete database code. it’s necessary if you set up exceptions, otherwise it’s pointless.

12

then…the question becomes…are exceptions needed?
And always in relation with the code you see which already has error-checking mechanisms in place.

13

that depends how much error handling code you want to write. I personally prefer exceptions because they have some important advantages over return values.

the only thing you really need is error handling as such. whether you use return values, errors, or exceptions for that depends on your personal laziness.

14

What are the important advantages of exceptions-as you mention?
I don not make this question just out of curiosity…in the beginning of this topic you see the error checking code I use for the prepared statement.

I am afraid that with the above approach some errors are not detected.

15

exceptions travel the call stack. i.e. you can handle the problem at a position in your code, where it is most appropriate. esp. with output this is usually far away from where those errors occur (a database failure can thus be handled in the output section). additionally you don’t have to take care of exception propagation (which you would have to do if you would only consider return values)

exceptions have lots of different types. there are over a dozen built-in exception classes and you can build your own as well. therefore it is dead easy to distinguish between a database exception and an exception thrown due to invalid input.

exceptions carry a trace, that is a list of every function/method with their arguments and the position in that function that the exception went through before it was caught.

some built-in functions/classes can throw exceptions automatically (PDO, MySQLi, DateTime) so you don’t need to throw them yourself.

16

I got your point…since this topic is about SQL error checking(I am using MySQLi) than you might agree that return values might be OK.-in the future I intend setting more elaborate error-checking mechanisms.

And that exception would be helpful in other type of PHP code-not related to SQL statements

17

I got your point…since this topic is about SQL error checking(I am using MySQLi) than you might agree that return values might be OK.-in the future I intend setting more elaborate error-checking mechanisms.

And that exception would be helpful in other type of PHP code-not related to SQL statements