On Tue, May 7, 2013 at 2:49 PM, Sebastian Krebs <krebs....@gmail.com> wrote:
> 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. > I'd say that's up to the developer. If foo2-5 aren't intended to be publicly accessible to the initial foo1() call. I'm not proposing that the behavior of existing trigger_error() calls should be modified - rather that new parameters be added or something whereby the line number / file name can be specified. If they're not then PHP should show the line and file on which the trigger_error() call was made.