Najlepsza praktyka obsługi błędów przy użyciu PDO

To bardzo dobre pytanie, ale na samym początku jest jedna błędna przesłanka:raportowanie błędów dla PDO jest oddzielone od raportowania błędów dla całej witryny. Co nie ma większego sensu:błędy PDO pod każdym względem są takie same jak inne błędy — błędy systemu plików, błędy HTTP i tak dalej. W związku z tym nie ma powodu, aby ustanawiać raportowanie błędów wyłącznie PDO. Wszystko, czego potrzebujesz, to odpowiednio ustawić raportowanie błędów w całej witrynie.

Istnieje również jedno błędne założenie dotyczące niedostępności php.ini:zawsze możesz ustawić dowolną dyrektywę konfiguracyjną za pomocą funkcji ini_set(). Tak więc nie ma jednego powodu ustawienia raportowania_błędów na katastrofalny poziom 0.

Aby odpowiedzieć na pozostałe pytania, wystarczy trochę zdrowego rozsądku.

Co o sobie myślisz? Czy dobrze jest wyświetlać użytkownikowi komunikaty o błędach systemu? Czy dobrze jest pokazywać złośliwemu użytkownikowi wewnętrzne elementy systemu?

Czy masz co do tego jakieś zastrzeżenia?

Nie sądzisz, że to całkiem sprzeczny pomysł - logowanie błędów bazy danych do bazy danych?

Pokazałeś już to:wyświetl w dev i zaloguj się prod. Wszystko jest kontrolowane w całej witrynie za pomocą kilku prostych opcji konfiguracyjnych.

NIE używać w ogóle bloku try-catch do raportowania błędów. Nie napiszesz bloku catch z przyjaznym komunikatem o błędzie dla każdego zapytania w Twojej aplikacji , jak sugeruje druga odpowiedź, prawda?

Dlatego Twój kod musi być

<?php
  // Error handling
  error_reporting(-1);
  ini_set('display_errors',0);
  ini_set('log_errors',1);

  // Get credentials from outside document root
  require_once('../settings.php');

  // Tests connection to database
    $dbh = new PDO(
            sprintf(
              'mysql:host=%s;dbname=%s;port=%s;charset=%s',
              $settings['host'],
              $settings['name'],
              $settings['port'],
              $settings['charset']
            ),
            $settings['username'],
            $settings['password']
    );
    // Prevents emulated prepares and activates error handling
    // PDO::ERRMODE_EXCEPTION
    $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
    $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Przejdźmy teraz do pytania, które zadałeś w komentarzu.

Niestandardowy ekran błędu to zupełnie inna sprawa, a twój kod jest z nim szczególnie zły. Nie powinien to być błąd 404 ani przekierowanie HTTP (to bardzo złe dla SEO).

Aby utworzyć niestandardową stronę błędu, musisz użyć funkcji serwera WWW (preferowane) lub obsługi błędów w skrypcie PHP.

W przypadku napotkania błędu krytycznego (a jednym z nich jest niezłapany wyjątek), PHP odpowiada nie statusem HTTP 200 OK, ale statusem 5xx. Każdy serwer sieciowy może wykryć ten stan i wyświetlić odpowiednią stronę błędu. Np. dla Apache byłoby to

ErrorDocument 503 server_error.html

gdzie możesz napisać dowolne wymówki.

Lub możesz skonfigurować niestandardowy program obsługi błędów w PHP, który będzie obsługiwał również wszystkie błędy PHP, przykład można zobaczyć w artykule, który napisałem na ten temat:Niewłaściwe użycie try..catch.