PHPのドキュメントを理解していると、カスタムエラーハンドラー（すべてのエラーをキャッチできない）を設定すると、デフォルトのphpエラーハンドラー（すべてのエラーをキャッチできると思います:)が非アクティブになります。
これが正しければ、カスタムエラーハンドラを設定する目的はありますか？私は常にerror_reporting（-1）を保持しているので、とにかくエラーログにすべてのエラーを取得する必要がありますよね？
ユーザーエクスペリエンスに関しては、これらのエラーをカスタムの方法で明示する目的がわかりません。なぜユーザーにエラーを表示させたいのでしょうか。本番環境では、常にdisplay_errorsをオフに設定します。
本番環境では、サイトがクラッシュしたときにユーザーに何かを伝えたいと思うかもしれません。また、ユーザーset_error_handlerにコードや行番号などの醜いものが表示されないようにしながら、かなりのエラーメッセージを表示する方法を提供します。通常のPHPエラーハンドラーがキャッチするランタイムエラーをキャッチします。
の使用を避ける理由はありません。エラーが発生したときに何もset_error_handler表示しない方が確実に望ましいです。
カスタムエラーハンドラの設定は、他の場所では処理されないエラーを処理するキャッチオールハンドラを設定するためのものです。スクリプトがまったく実行されないエラー（致命的な構文エラーなど）を除いて、すべてのエラーをキャッチ できます。
falseまた、エラー処理関数から戻ると、組み込みのPHPエラーハンドラーが介入することも指摘しておく必要があります。
アプリケーション内の特定の種類の例外の特別なロギングのためにこれが必要になる場合があります。
これが正しければ、カスタムエラーハンドラを設定する目的はありますか？私は常にerror_reporting（-1）を保持しているので、とにかくエラーログにすべてのエラーを取得する必要がありますよね？
error_reportingは、報告するエラー（警告、通知など）を指定します。これは、ログに表示されるものとは何の関係もありません。error_reportingを0に設定すると、ログに記録されません。ログに記録するが顧客には表示しないようにする場合は、display_errors=Offを使用します。
ユーザーエクスペリエンスに関しては、これらのエラーをカスタムの方法で明示する目的がわかりません。なぜユーザーにエラーを表示させたいのでしょうか。本番環境では、常にdisplay_errorsをオフに設定します。
「死の白い画面」ではなく、「何か」がうまくいかなかったというメッセージを見たい。これは、カスタムエラーハンドラを使用して簡単に行うことができます。だから、ええ、それは目的を持っています。