YII_DEBUG false shows PHP notice errors and stops

Archives Bug Discussions
1

Using latest yii-1.1.8.r3324 running with php 5.3.6 on apache 2.2

PHP is set in php.ini to log but not display errors:

display_errors = Off

display_startup_errors = Off

error_reporting = E_ALL | E_STRICT

error_log = /var/www/errors/php-errors

YII_DEBUG and YII_TRACE_LEVEL lines are commented out in index.php so that we are running in Production mode.

Now here’s the issue:

When Yii encounters a session_start() call when a session is already started, the app stops and displays:

[b]Error 500

A session had already been started - ignoring session_start()[/b]

and then no further page content except the page footer image.

I would have expected that with YII_DEBUG false, as it is by default with the lines in index commented,

that no errors would be displayed and the script would run as normal. Instead the script is balking over a simple notice error which should only be logged.

Looking inside the framework YiiBase.php found the define YII_ENABLE_ERROR_HANDLER

If I define(‘YII_ENABLE_ERROR_HANDLER’,false) in my index file then the errors don’t show and the scripts produce normal page content.

But I feel I should not have to do that when YII_DEBUG is defined as false.

Thanks for your comments.

2

After a server package upgrade on my test system,

one that included upgrade to php 5.3.9, I intentionally set


error_reporting = E_ALL | E_STRICT

per the php.ini instructions to set Development Value: E_ALL | E_STRICT and the error returned.

Not recalling the previous issue, Googled the error and found my own post unanswered <grin />

After much trial and error found that even with these settings in php.ini


display_errors = Off

display_startup_errors = Off

error_log = /var/www/errors/php-errors

Yii still halted as before with error 500 on notice errors like session already started.

Once the error_reporting was set to either

E_ALL & ~E_NOTICE

or

E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR

the problem goes away. So there’s the workaround in case anyone else runs across this.

3

This is not a workaround or a Yii problem… it’s how PHP works…

for more info check the PHP documentation - http://php.net/manual/en/errorfunc.configuration.php

4

Thanks for your reply.

I am familiar with that reference and as I read it indicates that the default YII behavior is not how PHP works.

What you say would be the case except for the fact that YII overrides the default PHP error handling behavior in CApplication::initSystemHandlers() like so:

            if(YII_ENABLE_ERROR_HANDLER)


                    set_error_handler(array(&#036;this,'handleError'),error_reporting());

By default PHP neither halts for a NOTICE error nor displays it to the user when set in recommended production mode with

error_reporting = E_ALL & ~E_DEPRECATED

and

display_errors = Off

The PHP recommended production error_reporting setting

E_ALL & ~E_DEPRECATED

does not inhibit reporting of NOTICE errors but they are not displayed to the user with display_errors = Off, and scripts are not halted for these type of errors.

When I test outside of YII using simple scripts containing NOTICE errors, those scripts are not halted and no error message is displayed to the user.

However, by contrast, with PHP in recommended production mode, when YII in production mode encounters a simple PHP NOTICE error it both halts (error 500) and displays the NOTICE error.

This is not the default PHP action, i.e., it is not the way PHP works.

5

Hm… interesting thoughts, but in my oppinion it is better to be forced to write code that does not throw notices…

In most cases when a notice is thrown php does something you would not expect, and shows a notice about what it is doing now, not halting application.

To build a clean good working application you should avoid any notice to prevent unexpected behavior.

6

I would like to counter the argument.

There are recoverable and unrecoverable errors.

Example:




$fp = fopen('/some/dir/somefile.txt','w'); // Can throw errors

if($fp === FALSE)

 //dosomething

There could be many reasons why fopen fails and just halting doesn’t allow us to deal with it. The only option in this case would be to suppress the errors with ‘@’ which is bad practice and makes bugs even harder to find.

With a standard php program it logs the errors but allows you to continue the program.

Halting can be useful at times but I think halting should be opt-in.

7

If anyone finds a workaround for this in Yii that logs the warnings and notices but doesn’t halt processing, please post it here. I’ll do the same, if I can figure out a way to do it.

1 Like