Re: idea: letting the line number and file name be set via user_error
Am 7.5.2013 um 21:07 schrieb Sebastian Krebs <[email protected]>:
>
>
>
> 2013/5/7 Bob Weinand <[email protected]>
>
> Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs <[email protected]>:
>
> > On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson <[email protected]> wrote:
> >
> >> If you do user_error('whatever') it'll show, as the line number for
> >> that
> >> error, the line number on which that user_error() call is made. It'd be
> >> nice if you could control the line number and file name that was displayed.
> >> eg.
> >>
> >> <?php
> >> function test() {
> >> user_error('whatever');
> >> }
> >>
> >> test();
> >> ?>
> >>
> >> That'll say "Notice: whatever in ... on line 4" (ie. the line that the
> >> user_error is on) instead of "Notice: whatever in ... on line 7" (ie. the
> >> line that the call to the test() function is made).
> >>
> >> If the displayed line numbers could be controlled by user_error then
> >> debug_backtrace could be used to get the desired line number / file name to
> >> display.
> >>
> >
> > line 3, but I suppose that is just a typo on your part.
> > the default error handler reports the line when the actual error is
> > generated and it also provides a backtrace so you can see the callchain for
> > the execution.
> > I think that this is a sensible default, and allowing to fake that from the
> > userland would make the debugging of the problems harder, as many/most
> > people would look up the file:line number and would be surprised that there
> > is no E_USER_* thrown there.
> > Additionally I'm not sure how/where would you get your fake line numbers.
> > You would either need to hardcode those in your application and make sure
> > that the reference and the actual content of your file is in sync (you will
> > screw yourself over sooner or later) or you would use __LINE__ + offset
> > which is still error prone..
> >
> > I didn't like this proposal.
> >
> > --
> > Ferenc Kovács
> > @Tyr43l - http://tyrael.hu
>
> And today we have the problem that we cannot use in any useful manner trigger_error in
> libraries, when we don't know where the error originates from.
>
> Still don't get it:
>
> if ($errorCond) {
> trigger_error();
> }
>
> The error orginates from at most one line before...
And $errorCond may have some long complicated preprocessing by internal functions of the framework I
don't want to know about, so that I cannot imagine instantly what's going on?
> You debug today trigger_error's in libraries with putting a debug_print_backtrace behind
> the trigger_error.
>
> I use a debugger :X
I don't know why, but I find it more comfortable to debug with gdb than with xDebug. With gdb
it's only setting a break into the trigger_error function and then use zbacktrace... But for
debugging on some production system because only there something goes wrong for some reason, I
wouldn't want to install xDebug (which will be loaded at every request...).
> I think you should be able to track down the error source without manipulating any library code
> in the best case (yeah, there exist Exceptions (there you can add a backtrace) too, but you have to
> catch them, if not your script will abort; but I only need a notice...)
>
> What I'm doing now is using my own error handler, add a "called at [line:file]"
> and output the string myself (via fwrite to STDERR). I don't think that this is the right way,
> this seems to me more like a temporary solution.
>
> Please change there something that makes it easier to debug trigger_error's notices. (But
> I don't know if only adding a third parameter to trigger_error is enough...)
>
>
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
> --
> github.com/KingCrunch
Bob
Thread (20 messages)