Re: idea: letting the line number and file name be set via user_error

Am 7.5.2013 um 21:49 schrieb Sebastian Krebs <krebs.seb@gmail.com>: > > > > 2013/5/7 Bob Weinand <bobwei9@hotmail.com> > > Am 7.5.2013 um 21:07 schrieb Sebastian Krebs <krebs.seb@gmail.com>: > >> >> >> >> 2013/5/7 Bob Weinand <bobwei9@hotmail.com> >> >> Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs <tyra3l@gmail.com>: >> >> > On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson <zelnaga@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