Am 7.5.2013 um 21:49 schrieb Sebastian Krebs <[email protected]>:
>
>
>
> 2013/5/7 Bob Weinand <[email protected]>
>
> 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...).
>
> 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