[RESOLVED] By the way of error_reporting .......

whisher06

Hi anyOne.
I'd like to know what's the best
way to set the errors level in a
php script.
I mean during the test I set
error_reporting(E_ALL) on the
other hand when I put the script
on the real world for security reason
I set error_reporting (0).
Is it ok ? 🙂

laserlight

Set the error_reporting level in php.ini

whisher06

Hi.
Tks for the ready reply.
I'm not on my own server
but my web host allow me
to put in my web site
.htaccess file.
How could I set the value ?
Take care.

laserlight

I suggest that you have your own webserver on your computer so that you can test at home.

Weedpacket

php.ini-dist
; For several security-oriented considerations that should be taken
; before going online with your site, please consult php.ini-recommended
; and http://php.net/manual/en/security.php.

For example, in the section on Error Reporting in the cited section of the manual it says

One way of catching this issue ahead of time is to make use of PHP's own error_reporting(), to help you secure your code and find variable usage that may be dangerous. By testing your code, prior to deployment, with E_ALL, you can quickly find areas where your variables may be open to poisoning or modification in other ways. Once you are ready for deployment, you should either disable error reporting completely by setting error_reporting() to 0, or turn off the error display using the php.ini option display_errors, to insulate your code from probing. If you choose to do the latter, you should also define the path to your log file using the error_log ini directive, and turn log_errors on.

MarkR

You should set error_reporting to E_ALL in development AND production.

You should have a custom error handler which takes some suitable action (like logging the circumstances of the error and showing the user a friendly error message).

You DO NOT want to turn off error_reporting, as it will mean that errors go entirely unnoticed. That will mean that if your script does something which fails, it will charge headlong into oblivion anyway, wreaking havoc as it does.

If an error happens, no matter how small (YES, INCLUDING E_NOTICE), the script MUST STOP. It must not continue, as doing so could:

Corrupt data
Send the user misleading emails such as "Thankyou, your order has been confirmed" when it actually hasn't
Cause serious errors to go unnoticed in a production environment

DO NOT set error_reporting(0). Ever.

Mark

Installer

Mark -

Having error_reporting off won't prevent a script from halting on fatal errors, and it won't prevent setting up custom error handlers (which should be done in any case). Maybe I misread your post.

Of course, error_reporting should be left on and errors should be logged so that one knows what's going on.

whisher06

TKs so much buddies 😃
Nice hat weedpacket 🆒
Take care.

MarkR

Installer wrote:
Mark -

Having error_reporting off won't prevent a script from halting on fatal errors, and it won't prevent setting up custom error handlers (which should be done in any case). Maybe I misread your post.

No, you're right. Perhaps I should clarify it:

My custom error handlers respect the current level of error_reporting and will only terminate the script if the current error falls inside error_reporting.

This makes it possible for me to carry out operations which are expected to generate warnings (e.g. parsing tagsoup HTML) without them being interrupted by my error handler. To do this, I temporarily set the error_reporting level lower.

I also occasionally use the @ operator, but I feel it should be used sparingly as it can lead to very difficult to debug faults.

I appreciate that display_errors and error_reporting are independent. In fact error_reporting only really affects the default error handler, which isn't even called if you set up a custom one. Except that in mine, I maintain this behaviour.

My error handler typically halts on ANY unmasked error, not just fatals (which it can't trap anyway). This stops the "charging headlong into oblivion" system.

Mark