More valuable error message handling

php.internals

Michael Wallner

20 years ago
Hi, I think many people agree that PHPs means for a developer to get the last error message(s) are way suboptimal. INI(track_errors) and $php_errormsg or hacking some error handler magic are--despite sep. extension facilities--the only one that come to mind, both cumbersome and unintuitive. I therefore propose some new functionality with possibly this 3 new functions: - error_get_last() Get the last error message. - error_get_all() Get an array of all occurred errors. - error_clear_all() Reset error stack. Return values and parameters are subject to discussion, as well as when PHP puts errors into this stack, eventually if track_errors is enabled? Thoughts, objections, flames? PS: Sorry, if that comes through twice. Regards,
-- Michael

Lukas Smith

20 years ago
Michael Wallner wrote:
> - error_get_last() > Get the last error message.
my wish would be that this one should work even if track_errors is not enabled. regards, Lukas

Antony Dovgal

20 years ago
On 11.07.2006 14:38, Lukas Smith wrote:
> Michael Wallner wrote: > >> - error_get_last() >> Get the last error message. > > my wish would be that this one should work even if track_errors is not > enabled.
Yes, these functions should not depend on any INI directives.
-- Wbr, Antony Dovgal

Michael Wallner

20 years ago
Antony Dovgal wrote:
> On 11.07.2006 14:38, Lukas Smith wrote: >> Michael Wallner wrote: >> >>> - error_get_last() >>> Get the last error message. >> >> my wish would be that this one should work even if track_errors is not >> enabled. > > Yes, these functions should not depend on any INI directives.
I'm with Ilia and think that there should be the possibility to disable this and track_errors seems like the perfect and already existing fit. Regards,
-- Michael

Marcus Börger

20 years ago
Hello Michael, yep, here too. track_errors is an optimizations when you don't want to debug but simply use your app. best regards marcus Tuesday, July 11, 2006, 5:21:09 PM, you wrote:
> Antony Dovgal wrote: >> On 11.07.2006 14:38, Lukas Smith wrote: >>> Michael Wallner wrote: >>> >>>> - error_get_last() >>>> Get the last error message. >>> >>> my wish would be that this one should work even if track_errors is not >>> enabled. >> >> Yes, these functions should not depend on any INI directives.
> I'm with Ilia and think that there should be the possibility to > disable this and track_errors seems like the perfect and already > existing fit.
> Regards, > -- > Michael
Best regards, Marcus

Lukas Smith

20 years ago
Marcus Boerger wrote:
> Hello Michael, > > yep, here too. track_errors is an optimizations when you don't > want to debug but simply use your app.
thats why i said that i would like to atleast be able to get the last error without having to mess/check track_errors ini setting. i think this is an acceptable compromise to always store the last error, no? this covers 100% of all use cases i ever had where i would mess with the track_errors setting at runtime. regards, Lukas

Michael Wallner

20 years ago
Lukas Smith wrote:
> thats why i said that i would like to atleast be able to get the last > error without having to mess/check track_errors ini setting. i think > this is an acceptable compromise to always store the last error, no? > > this covers 100% of all use cases i ever had where i would mess with > the track_errors setting at runtime.
Here's a less impacting patch for an error_get_last() function: http://dev.iworks.at/PATCHES/error_get_last.diff.txt Can we agree on that?
-- Michael

Marcus Börger

20 years ago
Hello Michael, looks quite good now :-) If it were up to me i'd say commit. best regards marcus Monday, July 17, 2006, 12:03:43 PM, you wrote:
> Lukas Smith wrote:
>> thats why i said that i would like to atleast be able to get the last >> error without having to mess/check track_errors ini setting. i think >> this is an acceptable compromise to always store the last error, no? >> >> this covers 100% of all use cases i ever had where i would mess with >> the track_errors setting at runtime.
> Here's a less impacting patch for an error_get_last() function: > http://dev.iworks.at/PATCHES/error_get_last.diff.txt
> Can we agree on that?
> -- > Michael
Best regards, Marcus

Ilia A.

20 years ago
Looks good to me, although I'd prefer you returned an associated array rather then an object. On 17-Jul-06, at 6:03 AM, Michael Wallner wrote:
> Lukas Smith wrote: > >> thats why i said that i would like to atleast be able to get the last >> error without having to mess/check track_errors ini setting. i think >> this is an acceptable compromise to always store the last error, no? >> this covers 100% of all use cases i ever had where i would mess with >> the track_errors setting at runtime. > > Here's a less impacting patch for an error_get_last() function: > http://dev.iworks.at/PATCHES/error_get_last.diff.txt > > Can we agree on that? > > -- > Michael > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Ilia Alshanetsky

Zeev Suraski

20 years ago
Agreed - it looks good, but should return an array instead of an object. Zeev At 00:33 18/07/2006, Ilia Alshanetsky wrote:

Michael Wallner

20 years ago
Ilia Alshanetsky wrote:
> Looks good to me, although I'd prefer you returned an associated > array rather then an object.
What for do we have object dereferencing then? As gimmick or buzzword? $err = error_get_last(); echo $err["message"]; vs. echo error_get_last()->message; One can still cast the stdClass instance to an array.
-- Michael

Antony Dovgal

20 years ago
On 18.07.2006 13:38, Michael Wallner wrote:
> Ilia Alshanetsky wrote: >> Looks good to me, although I'd prefer you returned an associated >> array rather then an object. > > What for do we have object dereferencing then? As gimmick or buzzword?
Definitely not for returning errors. Array perfectly fits here.
> $err = error_get_last(); > echo $err["message"]; > > vs. > > echo error_get_last()->message;
And if there was no error before that - what would you get?
> One can still cast the stdClass instance to an array.
-- Wbr, Antony Dovgal

Ilia A.

20 years ago
Just because we have objects it does not mean we need to use them all the time. In this instance IMO it makes absolutely no sense to use an object, it only creates extra overhead. If you want the patch to be included in 5.2, please change the function to return an associated array. On 18-Jul-06, at 6:38 AM, Michael Wallner wrote:
> Ilia Alshanetsky wrote: >> Looks good to me, although I'd prefer you returned an associated >> array rather then an object. > > What for do we have object dereferencing then? As gimmick or buzzword? > > > $err = error_get_last(); > echo $err["message"]; > > vs. > > echo error_get_last()->message; > > > One can still cast the stdClass instance to an array. > > -- > Michael > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Ilia Alshanetsky

Michael Wallner

20 years ago
I wrote:
> I therefore propose some new functionality with possibly > this 3 new functions: > > - error_get_last() > Get the last error message. > > - error_get_all() > Get an array of all occurred errors. > > - error_clear_all() > Reset error stack.
Patch against 5_2: http://dev.iworks.at/PATCHES/errorstack.diff.txt Regards,
-- Michael

Michael Vergoz

20 years ago
Hi Mike For me +1 :) I just have to look at something because i found a mem-leak where you patch (near) I will write a mail soon Mv- -----Original Message ----- From: "Michael Wallner" <mike@php.net> To: <internals@lists.php.net> Sent: Tuesday, July 11, 2006 4:53 PM Subject: [PHP-DEV] Re: More valuable error message handling

Andi Gutmans

20 years ago
I definitely think that for production apps we should be able to turn this off. It could significantly slow down apps.

Zeev Suraski

20 years ago
I think that error_get_last() makes sense, but not the other two. You can fairly easily implement that using an error handler if you'd like, and as Andi said, keeping track of all of the errors that happened on a production server doesn't make sense from a performance (and possibly even memory) perspective(s). Zeev At 13:35 11/07/2006, Michael Wallner wrote: