Am 7.5.2013 um 21:49 schrieb Sebastian Krebs <krebs....@gmail.com>:
>
>
>
> 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
My error messages look like:
Notice: _Some notice_ in _function_name_ called at [_file_:_line_] in _file_ on
line _line_ (function_name is the function which was called by the user)
This is useful: I can check exactly where the notice is issued and I know
where the function was called. But I have to go through the backtrace until I
encounter some function which isn't defined in my library.
This is the ideal case I think, but I don't know what would be the best API for
this...
Bob
