Click to See Complete Forum and Search --> : PHP and the anti-fail-fast brigade


MarkR
02-21-2006, 06:28 AM
Why is it, that a lot of PHP developers, seem to detest the idea of fail-fast? (http://failfast.com/)

Fail-fast has a great deal going for it. Yet PHP continues to fly in the face of overwhelming evidence, and suggest that it's a bad idea!

Even the manual pages (http://uk.php.net/manual/en/ref.errorfunc.php), say things like:


Enabling E_NOTICE during development has some benefits. For debugging purposes: NOTICE messages will warn you about possible bugs in your code.


This implies that E_NOTICE in production is not desirable! I find the opposite to be true. Errors are more likely to happen in production (because silly users use your app, and obnoxious robots hit your site etc), so you *REALLY* want to know about them. Even the smallest things, that E_NOTICE shows, are usually very siginificant.

In other languages, things that make E_NOTICE in PHP, often cause exceptions to be thrown (incidentally, I normally have my error handler throw exceptions in response to E_NOTICE or anything higher). The most common example is a missing key in an associative array.

---

Then open source applications[1], typically disable E_NOTICE and/or E_WARNING, because otherwise they'd create so many that the server would be significantly impeded just writing the error log!

Fail-fast is, IMHO, extremely good. All errors, warnings and notices should be enabled at all times in development *AND* production environments.

An E_NOTICE may indicate a bug which will subsequently cause data corruption - therefore, the application MUST NOT CHARGE HEADLONG INTO DESTRUCTION.

The old "oh, an error happened, but who cares, let's continue anyway!" days are long gone for me.

Mark

[1] Wordpress 2.0.1, wp-settings.php lines 65-66:

// Change to E_ALL for development/debugging
error_reporting(E_ALL ^ E_NOTICE);

vaaaska
02-21-2006, 08:05 AM
Hmmm...I almost always build stuff with this turned on. I do turn it off though once I know all is good (delivering it to the client).

thorpe
02-21-2006, 08:53 AM
Some error messages could pose a security risk, no point letting the client see them. If you can right them to a log, you should, but displaying them to the unsuspecting public could be even more problematic then not.

laserlight
02-21-2006, 08:53 AM
This implies that E_NOTICE in production is not desirable! I find the opposite to be true. Errors are more likely to happen in production (because silly users use your app, and obnoxious robots hit your site etc), so you *REALLY* want to know about them. Even the smallest things, that E_NOTICE shows, are usually very siginificant.
Take a look at php.ini-recommended, and you will find that error_reporting is set to E_ALL with display_errors off and log_errors on. Note also that php.ini-recommended is introduced with the comment that using it "is warmly recommended for production sites".

php.ini-dist, on the other hand, has error_reporting set to E_ALL & ~E_NOTICE with display_errors on and log_errors off. I personally use php.ini-recommended and toggle display_errors and log_errors for development purposes.

You might say that PHP's developers underestimated some aspects of security, and now they are trying to change it while staying compatible with existing PHP installations.

Then open source applications[1], typically disable E_NOTICE and/or E_WARNING, because otherwise they'd create so many that the server would be significantly impeded just writing the error log!
I agree that this is a rather strange way of going about open source development, since then technically skilled users wont be alerted to help fix the problem (i.e. failure to take advantage of the bazaar model). On the other hand, Wordpress is just one example, and the practice isnt solely inherent in open source development.

MarkR
02-21-2006, 08:54 AM
I'm not advocating showing error messages to users in production environments. I'm advocating actually *detecting* errors in production environments.

Whether you show the message to the user or not is a matter of policy; I typically don't.

Mark

Weedpacket
02-21-2006, 11:24 PM
This implies that E_NOTICE in production is not desirable!Being the irritatingly pedantic person I am, I have to point out that the statement neither says nor implies anything about PHP in a non-development environment.

The converse implication you can make is that if E_NOTICE does not have benefits, then it's not during development.