At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote:
I agree wholeheartedly, especially since one can set
reporting toE_ALLand
then ignore whatever one likes but with the way it is now
there is no way
of not being called for everything.
[...]
There seems to be some opposition to this fix. I don't quite
understand why but if there is a true need, we might need an
additional INI
option such as
custom_error_handler_error_reporting_mask which would be used.
How about a new optional 2nd argument to set_error_handler?
Cheers!
Mike
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: m.ford@leedsmet.ac.uk
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
Mike Ford wrote:
How about a new optional 2nd argument to set_error_handler?
Sounds like a good idea to me. Could be the mask of errors one wants to
get in the error handler.
So one could do
set_error_handler("handler", E_ALL); # Default, current mode
set_error_handler("handler", error_reporting()); # Honor settings
set_error_handler("handler", ...); # Custom mode
BTW: I think the documentation/examples to error_reporting() should
explain leaving out the parameter to not change the level and just get
the current level back.
Opinions?
- Chris
At 10:38 AM 12/19/2003 +0000, Ford, Mike [LSS] wrote:
At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote:
I agree wholeheartedly, especially since one can set
reporting toE_ALLand
then ignore whatever one likes but with the way it is now
there is no way
of not being called for everything.[...]
There seems to be some opposition to this fix. I don't quite
understand why but if there is a true need, we might need an
additional INI
option such as
custom_error_handler_error_reporting_mask which would be used.How about a new optional 2nd argument to set_error_handler?
I think that could be a good idea.
Andi
At 12:00 PM 12/19/2003 +0100, Christian Schneider wrote:
Mike Ford wrote:
How about a new optional 2nd argument to set_error_handler?
Sounds like a good idea to me. Could be the mask of errors one wants to
get in the error handler.So one could do
set_error_handler("handler", E_ALL); # Default, current mode
set_error_handler("handler",error_reporting()); # Honor settings
set_error_handler("handler", ...); # Custom modeBTW: I think the documentation/examples to
error_reporting()should
explain leaving out the parameter to not change the level and just get the
current level back.
Agree.
Andi
How about a new optional 2nd argument to set_error_handler?
But then scripts written with the proposed second argument will not be
backwards compatable.
I like the idea put forth earlier about only calling custom error handlers
when the error reporting level mask is met.
--Dan
--
FREE scripts that make web and database programming easier
http://www.analysisandsolutions.com/software/
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
4015 7th Ave #4AJ, Brooklyn NY v: 718-854-0335 f: 718-854-0409
How about a new optional 2nd argument to set_error_handler?
But then scripts written with the proposed second argument will not be
backwards compatable.
It is when it's optional and the default is the current behavior.
Derick
But then scripts written with the proposed second argument will not be
backwards compatable.It is when it's optional and the default is the current behavior.
Pardon me. Looks like PHP 3 behavior is still stuck in my brain...
Thanks,
--Dan
--
FREE scripts that make web and database programming easier
http://www.analysisandsolutions.com/software/
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
4015 7th Ave #4AJ, Brooklyn NY v: 718-854-0335 f: 718-854-0409
Daniel Convissor wrote:
It is when it's optional and the default is the current behavior.
Pardon me. Looks like PHP 3 behavior is still stuck in my brain...
No, you were right. A script using
set_error_handler("handler", error_reporting());
will get "Wrong parameter count for set_error_handler()" for PHP4.
So you force people to lock their code to PHP5 if they want to use the
new semantics. Not good for migration.
Another approach would be that set_error_handler() copies the current
error_reporting mask. But that leads to confusing situations if
error_reporting is changed later on. Would need good documentation to
explain it.
After thinking about it I come to the conclusion that coupling the error
handler to error_reporting is the right thing to do. I believe we can
live with the very rare case where people expect the error handler to
be called for everything AND they have error_reporting to something
else than E_ALL. That would also remove a WTF-situation (I was quite
surprised when my error handler got called for E_NOTICE even though I
disabled it in error_reporting).
- Chris
Daniel Convissor wrote:
It is when it's optional and the default is the current behavior.
Pardon me. Looks like PHP 3 behavior is still stuck in my brain...
No, you were right. A script using
set_error_handler("handler",error_reporting());
will get "Wrong parameter count forset_error_handler()" for PHP4.So you force people to lock their code to PHP5 if they want to use the
new semantics. Not good for migration.
This is not called backwards compatibility, but forwards compatibility.
Don't worry about this, as PHP wasnever really forwards compatible
anyway.
Derick
Don't worry about this, as PHP wasnever really forwards compatible
anyway.
I, and lots of people, need to worry about it. I write code that uses
PHP. Much of it is for general public consumption. Some is for sale at
significant cost. I have to write stuff once and have it work anywhere.
The proposed behavior of having error handlers called only when the
reporting bitmask is met is great. Makes things better in PHP 5 and
doesn't have real negative impacts for code written expecting PHP 4's
behavior.
Adding an optional argument has the worst of both worlds. In order to
take advantage of it, one must lock your code into PHP 5.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Daniel Convissor wrote:
I, and lots of people, need to worry about it. I write code that uses
I second that.
Adding an optional argument has the worst of both worlds. In order to
take advantage of it, one must lock your code into PHP 5.
In this specific case I can live with an optional argument (even though
I think it is pure bloat) because I can't use set_error_handler with
PHP4 anyway due to bug #25547. [As soon as this bug gets fixed and I
could use it though I'll hate myself for accepting the optional
parameter because I'll have to add a "if (version_compare...)" to my
code :-}].
- Chris
Christian Schneider wrote:
Daniel Convissor wrote:
Adding an optional argument has the worst of both worlds. In order to
take advantage of it, one must lock your code into PHP 5.
It doesn't work this way in PHP4 anyway. So if you really must use this
feature (I think I would) you can live with being locked to PHP5. Because
when you use this feature you must anyway provide other means for your
scripts to handle this in PHP4, so a version_compare() can't kill you.
IMHO this parameter is a good thing. I've always wanted it.
+1 from me for optional parameter.
-10 for anyhting like 'use current error_reporting() setting' or 'just
change the behavior from PHP4 to PHP5' (you need version_compare() again).
Both of these proposals are equally confusing.
Lenar
Christian Schneider wrote:
Daniel Convissor wrote:
Adding an optional argument has the worst of both worlds. In order to
take advantage of it, one must lock your code into PHP 5.It doesn't work this way in PHP4 anyway. So if you really must use this
feature (I think I would) you can live with being locked to PHP5. Because
when you use this feature you must anyway provide other means for your
scripts to handle this in PHP4, so aversion_compare()can't kill you.IMHO this parameter is a good thing. I've always wanted it.
+1 from me for optional parameter.-10 for anyhting like 'use current
error_reporting()setting' or 'just
change the behavior from PHP4 to PHP5' (you needversion_compare()again).
Both of these proposals are equally confusing.
Yup, I agree with this. If it should be changed, then an optional
parameter is the way.
Derick
I, and lots of people, need to worry about it. I write code that uses
PHP. Much of it is for general public consumption. Some is for sale at
significant cost. I have to write stuff once and have it work anywhere.
If you are concerned about code working in PHP 4 and PHP 5, then you
should be writing your code to PHP 4 and it should still work in PHP 5
for the most part. If you would like to take advantage of this proposed
error reporting functionality, then you can use version_compare() and
adjust your logic accordingly for PHP5->PHP4 transitions..
PHP 5 already introduces a thousand new things that don't work in PHP 4.
I think trying to stop an improvement because it's not PHP 4 compatible
is a mistake.
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbook http://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=
I think trying to stop an improvement because it's not PHP 4 compatible
is a mistake.
We're not trying to stop an improvement, we're trying to define exactly
how to improve it.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
No, you were right. A script using
set_error_handler("handler",error_reporting());
will get "Wrong parameter count forset_error_handler()" for PHP4.
I don't really see the issue with PHP 5 code not being able to be ran in
PHP4. If that's the case, let's throw out all of the ZE2 OO stuff too
because that's not PHP 4 compatible either.
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbook http://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=
I don't really see the issue with PHP 5 code not being able to be ran in
PHP4. If that's the case, let's throw out all of the ZE2 OO stuff too
because that's not PHP 4 compatible either.
:)
In the LONG term, rewriting applications for PHP 5's new capabilties not a
problem and offers great benefits. In the mean time, applications will
need to run on both 4 and 5. It would be good if the error handling
behavior between the two allow for a graceful transition.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409