When learning, developing, and debugging code/query(ies), you, the programmer/developer, want to see all php errors and the raw database statement errors so that you get immediate feedback as to any problems.
When you put your application onto a live/public server, you want to log all this error information, so that if a legitimate visitor manages to do something that you didn’t account for or a hacker/bot attempts or succeeds in breaking in, you will have a log of what occurred so that you can find and fix what’s wrong.
Most database statement errors are fatal problems, and are non-recoverable, e.g. database server is not running or mistakes in the sql query statement, that the visitor/hacker to your site doesn’t need to know anything at all about, because they cannot do anything to correct what’s causing them. In these cases, all the visitor/hacker should see is a http 500 error page, i.e. the current web page is not working, and no, cute messages like try again/later, being output by your code tells a hacker that they managed to trigger something at the code level, not just that the web page isn’t working.
The rest of the database statement errors, such as inserting/updating duplicate or out of range values, are recoverable, since the visitor can potentially alter the value(s) and submit the data again.
If you use exceptions for database statement errors, do as suggested in the linked to article, and NOT catch them in your code, php will catch them and use its error related settings to control what happens with the actual error information, via an uncaught exception error (database statement errors will ‘automatically’ get displayed/logged the same as php errors.) This will address the fatal, non-recoverable errors. If you are logging all php errors, which will now include the uncaught database statement errors, the response to the visitor will automatically be a http 500 page.
For recoverable database statement errors, you would have try/catch logic for the insert/update query, where you would test the error number in the catch code to see if the error that occurred is for something your code is designed to handle. If it is, you would setup a message for the user telling them exactly what was wrong with the data that they submitted. For all other error numbers, just re-throw the exception and let php handle it.
Short-version: only catch recoverable database statement errors in your code and let php catch all other database statement errors, where they will get displayed/logged the same as php errors do using the current php error settings.
For a SELECT query, it won’t fail on a live/public server due to anything that the visitor to your web site can do anything about and doesn’t need to know anything about a database error occurring at all.