これは非常に良い質問ですが、最初に1つの間違った前提があります。それは、サイト全体のエラー報告とは別に、PDOのエラー報告を行っているということです。これはほとんど意味がありません。すべての点でPDOエラーは、他のエラー(ファイルシステムエラー、HTTPエラーなど)と同じです。したがって、PDOのみのエラー報告を確立する理由はありません。必要なのは、サイト全体のエラーレポートを適切に設定することだけです。
php.iniにアクセスできないという誤った仮定もあります。それは、ini_set()関数を使用していつでも構成ディレクティブを設定できるということです。したがって、error_reportingを悲惨なレベルの0に設定する理由は1つではありません。
残りの質問に答えるのに必要なのは、少し常識です。
あなたは自分自身をどう思いますか?システムエラーメッセージをユーザーに表示するのは良いことですか?悪意のあるユーザーにシステム内部を表示するのは良いことですか?
これについて何か異議はありますか?
データベースエラーをデータベースに記録することは、まったく矛盾する考えだと思いませんか?
あなたはすでにそれを示しました:devに表示し、prodにログインします。すべては、いくつかの簡単な構成オプションによってサイト全体で制御されます。
エラー報告にtry-catchブロックを使用しないでください。 アプリ内のすべてのクエリに対してわかりやすいエラーメッセージを含むキャッチブロックを作成することはありません。 、他の回答で示唆されているように、あなたは?
したがって、コードは
である必要があります<?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);
コメントであなたが表明した質問に移りましょう。
カスタムエラー画面は非常に異なる問題であり、コードは特に問題があります。 404エラーであってはならず、HTTPリダイレクトを使用する必要もありません(これはSEOにとって非常に悪いことです)。
カスタムエラーページを作成するには、Webサーバー機能(推奨)またはPHPスクリプトのエラーハンドラーのいずれかを使用する必要があります。
致命的なエラーが発生した場合(およびキャッチされなかった例外は1つです)、PHPは200 OK HTTPステータスではなく、5xxステータスで応答します。そして、すべてのWebサーバーはこのステータスをキャッチし、それに応じたエラーページを表示できます。例えば。 Apacheの場合は
ErrorDocument 503 server_error.html
言い訳を書くことができる場所です。
または、すべてのPHPエラーも処理するカスタムエラーハンドラーをPHPで設定できます。例は、この問題について書いた記事にあります。 try..catchの(不適切な)適切な使用。