Feature detection breaks when errors are converted to exceptions

[shadowhand]

The Kohana framework converts errors into exceptions. This causes the feature detector to throw an exception incorrectly.

ErrorException [ 4 ]: syntax error, unexpected '?', expecting variable (T_VARIABLE) ~ vendor/eloquent/phony/src/Reflection/FeatureDetector.php(532) : eval()'d code [ 1 ]

[ezzatron]

Thanks for the report!

There must be some other factor here, because Phony's test suite runs with a similar error handler in place, converting errors to exceptions. The same approach is also used at my workplace, and causes no issues.

There's probably still some deficiency in the feature detector that's causing this. I was working on a cleanup over in the feature-detector-review branch. It has some changes that I think may fix this issue, to do with the types of exceptions that are caught and re-thrown inside the feature detector. If possible, would you be able to try this branch and see if you get better results?

Alternatively, could you help me out with some steps to reproduce this, so I can investigate? Is there an existing repo I can clone perhaps?

[shadowhand]

Same error with feature-detector-review branch. The error is happening because of type.nullable check. However, I managed to find the actual problem, which is that Kohana catches errors on shutdown and then throws an exception. Turning off this functionality allows Phony to operate normally.

[ezzatron]

Glad you found a workaround.

I've been thinking about ways to mitigate this, but error_clear_last() isn't available until PHP 7, and it seems that before that, there's no good way to clear the error returned by error_get_last(). It might still be worthwhile to use error_clear_last() when it is available.

[shadowhand]

We're nowhere near PHP 7 compatibility with Kohana right now. Good to know that function exists though.

[ezzatron]

This is just an idea, but perhaps the error handler could hang on to the last error it saw, and the fatal handler could only report on it if it hasn't already been handled by the error handler.

The logic being that if it's already passed through the error handler, then it's already been handled by the time the fatal handler sees it.