Cause⌗

Previously, our company’s project was upgraded from 5.2.* to 5.8.*. Because many parts of the code lacked strict validation, such as directly accessing array values, it resulted in Notice errors: Key does not exist.

We then set the following code in App\Providers\AppServiceProvider:

if ($this->app->environment() == 'production') {
    // Ignore Notice and Warning
    error_reporting(E_ALL^E_NOTICE^E_WARNING);
}

After testing, we found that pages that previously showed errors no longer threw exceptions. We thought this would solve the issue. However, in the following days, we still frequently received notification emails from Sentry about similar errors related to undefined array keys.

Investigation⌗

So I debugged the code in the local development environment and finally discovered that the problem was caused by Sentry’s capture mechanism. When Notice and Warning exceptions occur, although they are ignored at the PHP level, Sentry’s package can still capture them and send them to Sentry.

After researching Sentry’s documentation, I finally found that we can specify which error types to report through the configuration file:

return [
    'dsn' => env('SENTRY_DSN'),
    'server_name' => env('SERVER_NAME'),
    'environment' => env('APP_ENV'),
    'error_types' => E_ALL^E_NOTICE^E_WARNING,
    'attach_stacktrace' => true,

    // capture release as git sha
    // 'release' => trim(exec('git log --pretty="%h" -n1 HEAD')),

    // Capture bindings on SQL queries
    'breadcrumbs' => [
        // Capture Laravel logs in breadcrumbs
        'logs' => true,

        // Capture SQL queries in breadcrumbs
        'sql_queries' => true,

        // Capture bindings on SQL queries logged in breadcrumbs
        'sql_bindings' => true,

        // Capture queue job information in breadcrumbs
        'queue_info' => true,

        // Capture command information in breadcrumbs
        'command_info' => true,
    ],
];

The error_types above can be set to ignore specific exception types. With this setting, Notice and Warning exceptions will no longer be sent to Sentry.

However, from a code robustness perspective, this approach is just burying your head in the sand and not recommended. But in real projects, you may not be allowed to make significant changes to business logic, and you might not have the time to optimize these issues.

So we can only choose to temporarily ignore them and optimize later when time permits.

I hope this is helpful, Happy hacking…