[2.2][HttpKernel] ErrorHandler suppresses E_NOTICE error ending up with blank page in dev. #7499
Comments
|
The error you show here is a PHP Fatal error, which is handled by PHP and can't be caught during runtime, also app_dev.php doesn't guarantee the display of the error. It's up to you to set the diplay_errors and error_reporting in php.ini for your development environment (http://php.net/manual/en/errorfunc.configuration.php). By default php errors are logged. There is a PR that will add Fatal error logging to the application logs, until then php logs are the way to go. |
|
@xaben i have error display turned on in php but thanks for the references |
|
There is something else going on. I've just tried with the Symfony Standard Edition 2.2, and Symfony catches fatal errors and notices in the dev env. |
|
@fabpot
I am not well-versed enough to trace figure it out through symfony 2's internals |
|
Also looks like it depends of php sapi (mod_apache). |
|
It does not depends on php sapi. When |
|
Confirming this issue with nginx + php_fpm. A fatal error will be outputted to nginx's error log: but nginx will display Between having an error be outputted twice and a blank page being displayed, I will take the double output every time. |
|
Just a note, the way I replicated this issue: <?php
namespace Blogger\BlogBundle\Entity;
use Symfony\Component\Validator\Mapping\ClassMetadata;
use Symfony\Component\Validator\Constraints;
class Enquiry
{
public static function loadValidatorMetadata(ClassMetadata $metadata)
{
# Class MaxLength replaced by Length in sf 2.3 -> fatal error class does not exist
$metadata->addPropertyConstraint('name', new Constraints\MaxLength(50));
[...] |
|
It looks like this happens when both a notice and fatal happen at once if both the variable you're calling the method on is not defined (which throws a notice) and then the method as well is not defined (obviously:)) which throws a fatal for some reason everything just shuts down instead of processing both. |
|
I guess this is fixed in 2.3 #6474 |
|
no, it isn't fixed by this commits |
|
I can confirm this: composer.phar create-project symfony/framework-standard-edition symfony-standard 2.3.1 edit WelcomeController within indexAction() and add: $foo = null;
$foo->getBar();This will display the fatal error correctly. Now remove the $foo = null so we just have $foo->getBar();This would trigger both a notice for the undefined variable and an error for the call to a member on the non-object, but instead a blank page is displayed, unless something is wrong for my apache's php.ini development configuration settings. php.ini: error_reporting = E_ALL | E_STRICT but that does not seem to matter since error_reporting is set to -1 and display_errors set to 0. |
|
Looks like a duplicate of #8703 in which case this is a PHP bug. Feel free to reopen is the bug is different. |
The php error :
PHP Fatal error: Call to a member function getRepository() on a non-object
is suppressed and a blank page is rendered despite being in dev ( app_dev.php )
To replicate:
remove $em = $this->getDoctrine()->getManager(); from any crud action.
The text was updated successfully, but these errors were encountered: