First of all, I must admit that entire article is not very helpful and doesn't explain the error handling as it should. Rather, currently it's just an extended description of error reporting constants/modes.

Regarding examples, for the second one the answer is definitely not: the intended output will be exactly the same, as the example is focused on the Warning and not on Exception.
For the first example it depends, but still I am inclined to think that without try-catch it's better than with.

The only objection against removing try-catch is rather a potential leak of database credentials. This is actually the point that is very desirable to have explained in the article. Still, if we are going into such details, I would prefer something like

$ignore_args = ini_get('zend.exception_ignore_args');
ini_set('zend.exception_ignore_args', 1);
$dbh = new PDO($dsn, $user, $password);
ini_set('zend.exception_ignore_args', $ignore_args);

As it will keep the Exception but remove the credentials. But it's questionable still because the main purpose of the error message is to help us with debugging and the actual credentials used could be the key in pinpointing the problem.

And in a few months a code snippet that implements https://wiki.php.net/rfc/redact_parameters_in_back_traces can be added as well.

Without going into such details I'll prefer to just remove the try-catch, because catching exception only to echo it out is just a bad practice that shouldn't be endorsed by PHP manual. Echoing errors is bad by itself; and early catch prevent us from catching the Exception elsewhere. Basically we are ruining all the benefits the Exception gives us, effectively writing a code similar to that old if(!$con) die(mysql_error()) approach.

to explain what effect different pdo error modes have.

I added another example that better demonstrates this point.
While specific information about handling PHP Exceptions in general can be found on the relevant page linked above in the text.

On the bright side, this PR doesn't change any text, so if accepted, it won't require any translations to be made.

In a nutshell, it just displays the different outcome for the different modes. While actual handling is left for the user and can be learned from the article already linked in the text.

On the bright side, this PR doesn't change any text, so if accepted, it won't require any translations to be made.

Code examples still need to be adapted by the translators.