2013/5/7 Bob Weinand <bobw...@hotmail.com>
>
> Am 7.5.2013 um 21:07 schrieb Sebastian Krebs <krebs....@gmail.com>:
>
>
>
>
> 2013/5/7 Bob Weinand <bobw...@hotmail.com>
>
>>
>> Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs <tyr...@gmail.com>:
>>
>> > On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson <zeln...@gmail.com>
>> 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...).
>
Yes, "debugging by logs" is hard and debugging on a production is "not
ideal", thus you should try to reproduce the problem on your development
machine. Here you can have any extension you like :)
But to some my concerns up: I am unsure, if it is useful to let the error
message lie to you. It should tell you, where it appears, not where some
reason occured (or not), that might cause the call, that contains the line,
where the error occurs.
function foo1($a) {
foo2($a);
}
function foo2($a) {
foo3($a);
}
function foo3($a) {
foo4($a < 0 ? 0 : $a);
}
function foo4($a) {
foo5($a);
}
function foo5($a) {
if ($a == 0) trigger_error('Foo');
}
foo1(42); // OK
foo1(0); // Error
foo1(-42); // Error, but the wrong value now comes from foo3()
So now which line should the error report? Note, that in foo3 is a
condition, which makes it non-trivial to find out, where the wrong value
were injected the first time.
btw: Ever considered assert() to find such situations during development?
(Of course you should disable them on production)
Regards,
Sebastian
>
>
> 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
>
>
--
github.com/KingCrunch
