Hi @Mittineague thanks for your help, if I do var_dump(km_admin_new_username ($db_user_conn)); i get NULL
Considering you have a try-catch in place, I think the best thing to do would be to have tests inside the function that throw an exception
Have you established the database connection in Exception-Throwing mode?
Once the query is running, won’t this continue to display “Error” until you break into it, if the user already exists? That is, surely an infinite loop while you’re testing it? Could it be not showing "Error " because it never ends? Add another echo outside the do loop to see that it’s finishing.
That’s not entirely surprising as your function doesn’t return anything.
Hi @m_hutley this is my connection:
try {
// Connect to the user database
$db_user_conn = mysqli_connect(KM_DB_HOST, KM_DB_USER, KM_DB_PASSWORD, KM_DB_NAME);
// Connect to the master database
$db_master_conn = mysqli_connect(KM_DB_MASTER_HOST, KM_DB_MASTER_USER, KM_DB_MASTER_PASSWORD, KM_DB_MASTER_NAME);
} catch (Exception $e) {
// Render error view on page error 500
echo $twig->render('/km-errors/km-error-500.twig', array('error' => $e->getMessage()));
exit;
}
Hi @droopsnoot I wantent to test it to make sure it works fine ![]()
And you should. But if the username already exists, you’ll go into the catch, that will display an error, and then won’t your loop continue because it’s while true, so it’ll try to create it again, hit the catch, and so on? Perhaps add a break; in there as well, while you’re testing.
Hi, yes I wantend to make sure it goes into catch that is why I wanted to echo a sting inside the catch block to see if it actually gets printed but it doesn’t. It looks like my code is not able to catch the error " #1062 - Duplicate entry" but if I try to do an insert into a wrong table for examaple if i replace km_users with km_user in here
INSERT INTO km_user (km_user_first_name, km_user_last_name, km_user_role, km_user_username, km_user_email ) VALUES ('pippo', 'cipolla', '4', '446616', 'pippo@em.it')
then i can see the echo from the catch block.
I use set_error_handler function to manage all the errors so the problem might be there?
Sorry, I don’t know much about mysqli to know whether it might be.
Oh noes!
Repeat after me: I will never show details about exceptions to my end users.
You don’t know what those messages may contain; they may contain a lot of information that’s useful for people wanting to hack your site, like database names, table names, maybe even passwords if you’re real unlucky.
Just log errors somewhere, or send an email, but do not show it to the end user. No good will come of it.
Can you try adding mysqli_report(MYSQLI_REPORT_ERROR); there? That should make MySQLi throw exceptions, instead of using PHP’s error system (which should indeed be caught by your set_error_handler handler).
Hi yes I’m awar of it, I’m not in production yet, and also I’m using custom error messages with the function set_error_handler
Hi yes it works fine if I add mysqli_report(MYSQLI_REPORT_ERROR); into my config file but then I can’t show customized error using set_error_handler function
That’s what try/catch is for ![]()
Yes, it is just me being lazy, with set_error_handler I could trow a new general exception and use it in this way:
try {
// Here function to insert data in database
} catch (Exception $e) {
// Show error if insert query does fail
throw new Exception($e->getMessage(), KM_ERROR_CODE);
exit;
}
If I use mysqli_report(MYSQLI_REPORT_ERROR) then I get the error as Table ‘name of the table’ doesn’t exist because I suppose these are not caught by set_error_handler function, so in that case I should throw a new message like:
throw new Exception("custom error message", KM_ERROR_CODE);
Is it correct?
No. If you want to catch all exceptions somewhere, you’d need to use set_exception_handler. Which is basically the same as the error handler, but for exceptions instead of errors.
Hi @rpkamp i didn’t know about this function, but reading php7 documentation it says:
As with normal exceptions, these Error exceptions will bubble up until they reach the first matching catch block. If there are no matching blocks, then any default exception handler installed with set_exception_handler() will be called, and if there is no default exception handler, then the exception will be converted to a fatal error and will be handled like a traditional error.
This means that errors are not technically exceptions, however they can be caught like exceptions (which is a nice feature).
So with the set_error_handler I can catch the error and throw it as exception no?
It becomes a fatal error, so no, you can’t catch that. Once that’s thrown the PHP engine stops then and there.
If your function causes an error, you need set_error_handler to handle it
If your function throws an exception, you ideally try/catch it, trying to resolve the situation in the catch if possible, and otherwise let it bubble up to a handler defined using set_exception_handler.
So first you need to know whether your function is causing an error, or throwing an exception ![]()
That is amazing many thanks for your explanation it does make sense now ![]()
As a little background, PHP did not always used to have objects. Until PHP 3 there were only functions. PHP 4 kind of had objects, but not really (discussion for another day).
In those days without objects, it was impossible to throw exceptions, because those are objects too. So they had to use another way to get errors across to the user. That’s how the error system came to be.
Then later when objects were introduced, exceptions were introduced with them, but the error system staid. So then there were two systems, used in different scenarios with different ways of handling things.
The more modern PHP stuff, like PDO, can be set to throw exceptions, but this was not possible in the older code like the (now removed) MySQL extension.
The general recommendation now is to use exceptions whenever you can, and only fall back to using the error system when there is no way around it.