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"); ?>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
