PHP ENUMs errors aren't reported to Sentry

[LocalHeroPro]

Environment

self-hosted (https://develop.sentry.dev/self-hosted/)

Version

22.5.0.dev0

Steps to Reproduce

1. Write PHP ENUM

   //
   enum AwesomeEnum: int
   {
   case SOMETHING = 1;
   case ANOTHER_CASE = 2;
   }

2. Trigger error

   ///
   $enum = AwesomeEnum::from('some-string');

3. Laravel store that error in log, but

   //
   "exception":"[object] (TypeError(code: 0): App\\Enums\\AwesomeEnum::from(): Argument getsentry/sentry#1 ($value) must be of type int, string given)
   //

4. Sentry do nothing.

Expected Result

Sentry get errors from ENUMs errors.

Actual Result

Sentry don't show those errors.

[getsentry-release]

Routing to @getsentry/team-web-sdk-backend for triage. ⏲️

[Jean85]

This is really strange. An uncaught TypeError should be caught by Sentry anyway. Can you reproduce this issue in a smaller scale, like with a test here?

@stayallive do you think something in Laravel could interfere?

[stayallive]

It shouldn't AFAIK. @LocalHeroPro a few questions:

• did you register Sentry with the reportable or using the log channel?
• are other exception reported to Sentry?

[LocalHeroPro]

1. Like here: https://docs.sentry.io/platforms/php/guides/laravel/
2. Yes, proof:

[LocalHeroPro]

@Jean85 could you provide some example, link to that test?

[Jean85]

You can probably start from a PHPT test, which is very high level; try using this one as a starting point and replace the error with your case: https://github.com/getsentry/sentry-php/blob/master/tests/phpt/error_handler_captures_error.phpt

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[LocalHeroPro]

I have other issues that don't Sentry don't catch.

[2022-06-14 08:57:01] prd.ERROR: App\Services\Dpd\PackageService::sendPackage {"order_shipping_line_id":26264,"exception":"[object] (ErrorException(code: 0): DOMDocument::createElement(): unterminated entity reference             quo at /data/www/example.com/html/app/Services/Dpd/PackageService.php:196)

Why?

[Jean85]

Without any additional information, we're unable to help you. The standard installation should catch any uncaught exceptions by default. Maybe you have some additional configuration that is conflicting with Sentry? Are you using the default options or do you have any custom value set?

[LocalHeroPro]

As I can see, I have that configuration: https://github.com/getsentry/sentry-php/issues/1320#issuecomment-1131878371.

The standard installation should catch any uncaught exceptions by default

It means, if I catch exception using try catch, so that exceptions can't be reported in standard configuration? Example:

throw new UnexpectedValueException('Connection error. Check the correctness of the credentials.'); // will be reported to the Sentry

try {
    $e = 1 / 0;
} catch (Throwable $e) {
    // that will NOT be reported to the Sentry?
}

[Jean85]

If you have

try {
    $e = 1 / 0;
} catch (Throwable $e) {
    // no op
}

return;

yes, this does not get caught. No exception is rising, so we can't do anything about it. We may catch warning or deprecations, because they get to the error handler anyway, even if the flow is not interrupted. But otherwise you will not get them you'll have to add a manual catch of the exception by Sentry in the catch block.

[LocalHeroPro]

Exception is raised: we can't divide by zero, so catch blok catch exception.

[Jean85]

Raised and caught, also not rethrown.

Sentry SDK is able to automatically capture only uncaught exceptions.