Error handling (no redirect)

From: Date: Wed, 27 Nov 2002 00:17:25 +0000
Subject: Error handling (no redirect)
Groups: php.dev 
Request: Send a blank email to php-dev+get-91786@lists.php.net to get a copy of this message
Hi, having ported a site from ColdFusion to PHP in a very short time frame, I can safely say, ColdFusion is an overpriced templating system and not a scripting language. There is one convenience however, and that is that any error can be handled by the end user. I found it very inconvenient that parse errors can't be handled, but after a little talk with Derick, he came up with the 'tokenizer' extension. If you can tokenize it, it doesn't contain parse errors. So that's one thing. That still leaves some fatal errors, for which you cannot register an error handler. The general thought on php-dev seems to be, that you shouldn't commit files containing errors into production. This assumes, that php is only used in environments where staging servers and/or people understanding CVS is common. Most hosting environments don't provide these services and even in a controlled environment, it is not always possible to force this infrastructure into the business. Even if this is not a good argument: what's the reason for not handing fatal errors to an error handler? Or maybe it should be looked at better, which errors are considered fatal? I for one, don't understand, why a call to an undefined function, shouldn't be handled by an error handler, unless the undefined function is the error handler. Since an error handler, can only be registered when zend_is_callable returns true, and undefined functions are resolved in 'execute', via zend_hash_find, I can't see any conflict arrising. So - 2 questions here: What was the original reasoning, not to allow error handlers to handle fatal errors? Why can't a call to an undefined function, be an E_USER_ERROR (as a temp solution)? With kind regards, Melvyn Sopacua <?php include("not_reflecting_employers_views.txt"); ?>

« previous php.dev (#91786) next »