Hi!
Although I'm new here and I know I'm about to stir up a hornets' nest,
please allow me to introduce another error/exception proposal.
The problem for me as a php end-user currently is, that no coherent
error behaviour in php exists. Core functions only issue errors, intl
eg. suppresses all errors (if not enabled), pdo allows suppressing
errors, exceptions and errors - but only of level E_WARNING.
Whether I prefer suppressing errors, errors or exceptions, I always
run into problems:
- If I prefer suppressing errors, I cannot do so with any granularity;
always setting an resetting the error reporting functions is
cumbersome and messy (error-prone). - If I prefer errors, I have to take care of extensions that default
on suppressing them (like intl) with probably different methods
of enabling errors (ini or per object or...) and frankly, I cannot
count on the error level. - If I prefer exceptions, much of php doesn't support them at all and
extensions might have different facilities to enable them.
ErrorException is not really a solution, as exception information
(exception class, previous exception) is lost.
I therefore propose to let the user decide on the kind of error
behaviour; and with some granularity at that.
An extension would only ever call a common error function, with at least
error code and error message (plus desired error_level and exception
class if needed), whereas the "error configuration" not only decides on
whether showing the error (now) but also if it is an error or an
exception (new).
For more details, please have a look at:
http://wiki.php.net/rfc/enhanced_error_handling
(which is by no means complete or error free itself)
Regards
HPO
Hans-Peter Oeri wrote:
The problem for me as a php end-user currently is, that no coherent
error behaviour in php exists. Core functions only issue errors, intl
To be honest I prefer an inconsistent but stable error mechanism.
Allowing to change the error behaviour (e.g. something as extreme as
allowing to convert all internal errors to exceptions via ini setting -
I know that's not part of this proposal, just using it as an example)
leads to another inconsistency: Depending on the hosting provider and/or
frameworks/modules used you'd have to write different error handlers.
Suppose you want to write an open source application which has to work
on all different kind of environments: It seems to me that making error
behaviour configurable would make things harder rather than easier.
One of the nice things about PHP it's easy to learn and knowledge & code
is (most of the time) transferable amongst different instances of PHP.
Regards,
- Chris
Hi!
Christian Schneider wrote:
leads to another inconsistency: Depending on the hosting provider and/or
frameworks/modules used you'd have to write different error handlers.
I understand there are widely differing applications for php, that's why
I think backwards-compatibility and common defaults across installations
is a must. Changing defaults system-wide is always risky. In a
shared-hosting situation, the proposed error defaults must not be
changed, of course.
However, there are also many single-hosted applications that could
benefit greatly from configurability.
And note I don't only write pro global-configurability, but also
object-wise, like:
$T = new TranslationReader(...);
// say, on error, $a gets set to NULL, no error issued
$a = $T->get('nonexisting');
// change that behaviour for $T ONLY
$T->setErrorBehaviour( ERROR_THROW );
try {
// if ANY error in $T occurs, a corresponding exception is caught
[read many many translation strings]
}
catch( Exception $e ) {}
One of the nice things about PHP it's easy to learn and knowledge & code
is (most of the time) transferable amongst different instances of PHP.
And that's how it shall always be. I believe it should even give more
structure in a field where extensions currently fragment and render
php more complicated than it had to be.
Regards
HPO
Hans-Peter Oeri wrote:
Hi!
Christian Schneider wrote:
leads to another inconsistency: Depending on the hosting provider and/or
frameworks/modules used you'd have to write different error handlers.I understand there are widely differing applications for php, that's why
I think backwards-compatibility and common defaults across installations
is a must. Changing defaults system-wide is always risky. In a
shared-hosting situation, the proposed error defaults must not be
changed, of course.
Yeah, good luck with that. We have been imploring people for 10 years
to not have display_errors on in production with very little success.
You can have all the "MUST not" things in the documentation that you
want, nobody cares. If there is a shiny button to press, they will
press it. As soon as you make this configurable, everyone is going to
configure it differently almost instantly.
-Rasmus
Hi!
Rasmus Lerdorf wrote:
Yeah, good luck with that. We have been imploring people for 10 years
to not have display_errors on in production with very little success.
I agree but am convinced at least part of that problem lies in the
default php.ini, which - up to 5.2 - defaulted to display_errors=on! The
average user - not configuring anything - got that default and probably
got angry about production systems yelling secrets...
press it. As soon as you make this configurable, everyone is going to
configure it differently almost instantly.
Configurability already crept into the main distribution - like the
veteran display_errors and error_reporting or the newer error_level in
intl. I unconditionally prefer one proper concept to uncontrolled growth
of differing options.
Regards
HPO
Hi!
Rasmus Lerdorf wrote:
Yeah, good luck with that. We have been imploring people for 10
years
to not have display_errors on in production with very little
success.I agree but am convinced at least part of that problem lies in the
default php.ini, which - up to 5.2 - defaulted to display_errors=on!
The
average user - not configuring anything - got that default and
probably
got angry about production systems yelling secrets...
The problem is the average user got that and was happy with it, even
in production...
:-(
Keep in mind that PHP is SO easy that even a drummer can figure out
how to write a working script, no matter how bad the code is.
And then they toss it up on some server and have no problems for eons,
despite all the vulnerabilities, as they have no traffic to speak of.
Next thing you know, there are millions of sites like this, and
changing the default doesn't help.
People have customized php.ini and don't replace it if they can avoid
it, leaving the pre 5.2.x default in place forevermore.
--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch
Hi!
Christian Schneider wrote:
leads to another inconsistency: Depending on the hosting provider
and/or
frameworks/modules used you'd have to write different error
handlers.I understand there are widely differing applications for php, that's
why
I think backwards-compatibility and common defaults across
installations
is a must. Changing defaults system-wide is always risky. In a
shared-hosting situation, the proposed error defaults must not be
changed, of course.
How exactly do you propose to stop my clients' stupid web hosts from
being stupid and changing it, exactly?
Cuz I guarantee they'll manage to change it all crazy and make my life
miserable.
I can see the point of standardizing error handling.
But not the point of making it so configurable.
And the can of worms you open is that there is simply no agreement on
which standard to pick. This is unlikely to have changed with your
proposal.
Personally, I set up a set_error_handler and set_exception_handler,
and if anything I integrate over-rides that, they either do that well
and I leave it alone, or they screw it up and I comment it out. But
that's just me.
--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch