Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » RE: error_handler »

RE: error_handler

php.internals

Ford, Mike [LSS]

22 years ago
On 18 December 2003 23:38, Andi Gutmans wrote:
> At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote: > I agree wholeheartedly, especially since one can set > reporting to E_ALL and > 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

Christian Schneider

22 years ago
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

Andi Gutmans

22 years ago
At 10:38 AM 12/19/2003 +0000, Ford, Mike [LSS] wrote:
>On 18 December 2003 23:38, Andi Gutmans wrote: > > > At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote: > > I agree wholeheartedly, especially since one can set > > reporting to E_ALL and > > 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

Andi Gutmans

22 years ago
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 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.
Agree. Andi

Daniel Convissor

22 years ago
On Fri, Dec 19, 2003 at 10:38:00AM -0000, Ford, Mike [LSS] wrote:
> > 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

Derick Rethans

22 years ago
On Fri, 19 Dec 2003, Daniel Convissor wrote:
> On Fri, Dec 19, 2003 at 10:38:00AM -0000, Ford, Mike [LSS] wrote: > > > > 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

Daniel Convissor

22 years ago
On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans wrote:
> On Fri, 19 Dec 2003, Daniel Convissor wrote: > > > > 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

Christian Schneider

22 years ago
Daniel Convissor wrote:
> On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans 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

Derick Rethans

22 years ago
On Fri, 19 Dec 2003, Christian Schneider wrote:
> Daniel Convissor wrote: > > On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans 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.
This is not called backwards compatibility, but forwards compatibility. Don't worry about this, as PHP wasnever really forwards compatible anyway. Derick

Daniel Convissor

22 years ago
On Fri, Dec 19, 2003 at 04:00:34PM +0100, Derick Rethans wrote:
> > 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

Christian Schneider

22 years ago
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

Lenar Lõhmus

22 years ago
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

Daniel Convissor

22 years ago
On Fri, Dec 19, 2003 at 06:06:40PM +0200, Lenar Lõhmus wrote:
> > 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.
But then in order to have an error handler work in both PHP 5 and PHP 4 while avoiding the SLEW of var depricated notices, everyone is going to have to rewrite their error handlers to make them check for defined(E_STRICT) and then check if the error number is E_STRICT. A royal pain for a lot of PHP programmers, let alone the masses just using packages they downloaded from somewhere who will start to see var depricated notices all of a sudden and have no clue what's going on.
> -10 for anyhting like 'use current error_reporting() setting' or 'just > change the behavior from PHP4 to PHP5' (you need version_compare() again).
Please provide a real world example of why you would need version compare. Error handlers written for PHP 4 (expecting that all errors will go to the handler) will operate just fine under the new system (where only errors meeting the error reporting mask get sent to the handler). --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

Derick Rethans

22 years ago
On Fri, 19 Dec 2003, Lenar [ISO-8859-1] Lõhmus wrote:
> 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.
Yup, I agree with this. If it should be changed, then an optional parameter is the way. Derick

John Coggeshall

22 years ago
On Fri, 2003-12-19 at 10:13, Daniel Convissor wrote:
> 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/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-

Daniel Convissor

22 years ago
On Fri, Dec 19, 2003 at 03:50:42PM -0500, John Coggeshall wrote:
> > 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

Zeev Suraski

22 years ago
At 17:13 19/12/2003, Daniel Convissor wrote:
>On Fri, Dec 19, 2003 at 04:00:34PM +0100, Derick Rethans wrote: > > > > 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.
That simply isn't true. You may very well shut all errors off in production code, and rely on everything going through your error handler. It's not that rare at all.
>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.
As Derick said, PHP was never forward compatible (can't think of any language/platform that is). I, for one, think that the optional argument makes a great deal of sense. As a matter of fact, in practice - you can easily get forward-compatibility. Just supply it in both PHP 4 and 5 - extra arguments are ignored anyway (just provide @ to make sure of that). Zeev

Christian Schneider

22 years ago
Zeev Suraski wrote:
> argument makes a great deal of sense. As a matter of fact, in practice > - you can easily get forward-compatibility. Just supply it in both PHP > 4 and 5 - extra arguments are ignored anyway (just provide @ to make > sure of that).
Just checked it and no: set_error_handler does _not_ ignore the additional parameter, it fails and does _not_ install the handler on PHP4. Leave out E_ALL and it works like a charm. Am I missing something here? Script used to test: function handler() { echo "error!\n"; } @set_error_handler("handler", E_ALL); $a / 0; - Chris

Lenar Lõhmus

22 years ago
Christian Schneider wrote:
> Just checked it and no: set_error_handler does _not_ ignore the > additional parameter, it fails and does _not_ install the handler on > PHP4. Leave out E_ALL and it works like a charm. Am I missing something > here? > > Script used to test: > function handler() > { > echo "error!\n"; > } > > @set_error_handler("handler", E_ALL);
And why @? withou @ you see that there's a problem and can add version_compare() or rewrite something. At least you see which you don't when the behavior is just changed. Lenar

Daniel Convissor

22 years ago
On Fri, Dec 19, 2003 at 08:15:15PM +0200, Zeev Suraski wrote:
> > You may very well shut all errors off in > production code, and rely on everything going through your error > handler.
That already happens in ALL code which utilizes user defined error processing. Once a custom error handler is defined, all of the normal error processing gets turned off and error reporting settings are ignored. So, in PHP 4, there's no incentive for such programmers to set error_reporting to some other level.
> Just supply it in both PHP 4 and 5 - extra arguments are ignored anyway
Nope... CODE ---- echo phpversion(); set_error_handler('error_handler', 0); function error_handler($code, $text) { echo "<br />Handled... $text"; } $x; OUTPUT ------ 4.3.4 Warning: Wrong parameter count for set_error_handler() in y on line 4 Notice: Undefined variable: x in y on line 8
> (just provide @ to make sure of that).
Nope... Sure, adding a @ to the set_error_handler() call supresses the parameter count warning. But, since set_error_handler() failed, the error handler doesn't get called... OUTPUT ------ 4.3.4 Notice: Undefined variable: x in y on line 8 --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

Andrey Hristov

22 years ago
Daniel Convissor wrote:
>>Just supply it in both PHP 4 and 5 - extra arguments are ignored anyway >> >> > >Nope... > >CODE >---- >echo phpversion(); >set_error_handler('error_handler', 0); >function error_handler($code, $text) { > echo "<br />Handled... $text"; >} >$x; > >OUTPUT >------ >4.3.4 >Warning: Wrong parameter count for set_error_handler() in y on line 4 >Notice: Undefined variable: x in y on line 8 > > > > >>(just provide @ to make sure of that). >> >> > >Nope... Sure, adding a @ to the set_error_handler() call supresses the >parameter count warning. But, since set_error_handler() failed, the error >handler doesn't get called... > >OUTPUT >------ >4.3.4 >Notice: Undefined variable: x in y on line 8 > > >
We are not supposed to change 4.3.x right? So the code with @ is "working". The set_error_handler() is bailing out and everything is ok (as it has been till now). But this statement will work (if the decision is to add additional optional param) on PHP5 which is the aim. So an optional parameter and a @ in the front should help (no matter that @ is ugly). I think this is the idea of Zeev.
>--Dan > > >
Andrey

Daniel Convissor

22 years ago
On Fri, Dec 19, 2003 at 08:49:10PM +0100, Andrey Hristov wrote:
> So the code with @ is "working". The set_error_handler() is bailing out > and everything is ok
No, the erorr handler isn't being called and that's not okay. --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

Zeev Suraski

22 years ago
At 20:28 19/12/2003, Christian Schneider wrote:
>Zeev Suraski wrote: >>argument makes a great deal of sense. As a matter of fact, in practice - >>you can easily get forward-compatibility. Just supply it in both PHP 4 >>and 5 - extra arguments are ignored anyway (just provide @ to make sure >>of that). > >Just checked it and no: set_error_handler does _not_ ignore the additional >parameter, it fails and does _not_ install the handler on PHP4. Leave out >E_ALL and it works like a charm. Am I missing something here? > >Script used to test: >function handler() >{ > echo "error!\n"; >} > >@set_error_handler("handler", E_ALL); > >$a / 0;
Hrm, you're absolutely right, I erroneously mixed built-in and userspace function behavior. But my answer still stands - I still think that adding an extra argument is still the best solution, and that forward-compatibility ranks far below functionality in terms of importance. Sorry for the messup though. Zeev

Zeev Suraski

22 years ago
At 21:02 19/12/2003, Daniel Convissor wrote:
>On Fri, Dec 19, 2003 at 08:15:15PM +0200, Zeev Suraski wrote: > > > > You may very well shut all errors off in > > production code, and rely on everything going through your error > > handler. > >That already happens in ALL code which utilizes user defined error >processing. Once a custom error handler is defined, all of the normal >error processing gets turned off and error reporting settings are ignored.
Erm, that was kinda my point.
>So, in PHP 4, there's no incentive for such programmers to set >error_reporting to some other level.
Sure there is. You may shut off (or otherwise configure) error reporting site-wide, or application-wide, whereas you'd use the error handler only in parts of the app/site. Let alone the fact that it's not necessarily the same person developing the application and deploying it. In short, if you have applicative code in your error handler, it should not be dependant on site-specific setup of error_reporting. Zeev

Daniel Convissor

22 years ago
On Sat, Dec 20, 2003 at 01:06:25AM +0200, Zeev Suraski wrote:
> Sure there is. You may shut off (or otherwise configure) error reporting > site-wide, or application-wide, whereas you'd use the error handler only in > parts of the app/site.
Oh, I see what you mean. Yeah, problems would be caused under this scenario if custom error handlers are only triggered by the error reporting mask. I relent. Thanks, --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

Christian Schneider

22 years ago
Zeev Suraski wrote:
> Sure there is. You may shut off (or otherwise configure) error > reporting site-wide, or application-wide, whereas you'd use the error > handler only in parts of the app/site.
No one keeps you from changing the error_reporting level at certain points in your application so I can't see you point. But I guess we've settled for the additional parameter. So be it. - Chris

John Coggeshall

22 years ago
On Fri, 2003-12-19 at 09:43, Christian Schneider wrote:
> No, you were right. A script using > set_error_handler("handler", error_reporting()); > will get "Wrong parameter count for set_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/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-

Daniel Convissor

22 years ago
On Fri, Dec 19, 2003 at 03:48:23PM -0500, John Coggeshall wrote:
> > 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