What is the consensus on error checking, should I check every select, insert, update, delete etc. to make sure they worked, or is that overkill. Currently I mostly check user input to make sure there are no surprises.
Thanks
For database queries, you should only catch and handle exceptions (and if you are not using exceptions for database statement errors, you should be - this is the default setting now in php8+) in your code for user recoverable errors, such as when inserting/updating duplicate user submitted data. For all other query errors, all other type of queries, and for the connection, simply do nothing in your code and let php catch and handle any database exception, where php will use its error related settings to control what happens with the raw error information, via an uncaught exception error (database statement errors will ‘automatically’ get displayed/logged the same as php errors.) Non user recoverable errors are due to programming mistakes and the user/hacker visiting your site doesn’t need to know anything about them, except that the page they occurred on didn’t work (which is where logging errors on a live site will let you, the owner/developer, know what type of non user recoverable errors are occurring.)
You should trim input data, mainly so that you can detect if all white-space characters where entered, then validate all inputs before using them, to make sure that they meet the business needs of your application.
If you post an example of your code, more specific suggestions can be given. A lot of coding patterns found on the web contain as much as 2-3x too much typing of unnecessary things that don’t contribute to any programming goal.
As an addition to “do nothing”, you can of course run certain background tasks whereas you should rather “do nothing in public”.
A failing connection isn’t neccessarily a programming mistake. It can as well have external reasons as simple as the database being down.
Thus you may want to do things still like queing queries to a temp storage for when the db comes back up, or notify your DBA to urgently take a look.
The question that you always need to ask is:
Did this do any damage already that must be things rolled back? (like balance already deducted from prepaid account, but storing the order details failed)
Can this be recovered by the user? (like email already in use)
Can this be recovered by an admin? (like DB not reachable)
Can this be gracefully degraded through some fallback? (like if translation for a page in French missing, load and display English)
So this highly depends on your goal and what you want to achieve through your error handling. Thus you should do your custom error handling when you expect a benefit from doing it.
Hello,
I look at errors as user, database, and system error.
Please, consider that I am not a pro.
Some users may intentionally submit gibberish to break a system, so I validate and sanitise user inputs, so that they do not induce database errors with type and length mismatches.
I use try{} catch (Exception $e) {} to catch any errors from database operations and send responses to the error logs, and display a flash message to the user. I also implement that on some calls to classes/functions where a user may have attempted to alter GET query parameters that are processed.
Any error messages that you display to users must not give away the structure of the data, ‘E-mail not found’ as an example. A malicious actor may try e-mail addresses until one or more are found. Just show generic errors, without showing precisely what went wrong.
I also use CSRF tokens for all form submissions that mutate data, so those should be validated on the processing page as well.
The prevailing opinion is that error checking for each SELECT, INSERT, UPDATE, and DELETE can be excessive, but it’s crucial to handle errors where failures would be likely or have major consequences. For instance, verifying database operation results in critical places (such as financial transactions or authentication) is imperative. But for normal operations when the sample of failure is low and the implication is minimal, it may be sufficient to depend on simple checks, logging, and exception handling across the board. Robust user input validation is a good principle to avoid surprise problems, but complete error checking on every query is usually not required unless you are in a high-risk or mission-critical domain.