PHP error_reporting & set_error_handler: Balancing E_NOTICE suppression with critical error visibility

In a production PHP application, the goal is to reduce notification noise by suppressing E_NOTICE while still surfacing warnings, deprecations, and fatal errors. The configuration typically involves setting error_reporting = E_ALL & ~E_NOTICE, turning display_errors off, enabling log_errors, and optionally routing logs to a dedicated file or syslog.

When a custom handler is installed via set_error_handler, it can filter out non‑critical types, but fatal errors bypass the handler entirely. PHP 8’s ErrorException conversion also affects how E_DEPRECATED and E_USER_DEPRECATED are treated, which may change the visibility of legacy code warnings.

In containerized or serverless deployments, the default error_log path may point to the host’s syslog or an event log, leading to potential loss of error records if not explicitly configured.

Given these constraints, is it safe to rely on error_reporting(E_ALL & ~E_NOTICE) when using a custom error handler that logs only E_WARNING and above, considering that E_NOTICE can still be converted to an ErrorException in PHP 8? Additionally, how can we guarantee that fatal errors, which bypass user‑defined handlers, are still captured in a dedicated log file when the application runs inside a container?