Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67356 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4571 invoked from network); 7 May 2013 20:08:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 May 2013 20:08:08 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.103 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.103 blu0-omc2-s28.blu0.hotmail.com Windows 2000 SP4, XP SP1 Received: from [65.55.111.103] ([65.55.111.103:51995] helo=blu0-omc2-s28.blu0.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/76-06696-82F59815 for ; Tue, 07 May 2013 16:08:08 -0400 Received: from BLU0-SMTP111 ([65.55.111.71]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 13:08:06 -0700 X-EIP: [FLWxK1x1w8G7pF9mVzYvSY1qYGEQZnel] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Received: from [192.168.178.93] ([87.240.218.8]) by BLU0-SMTP111.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 13:08:03 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_6171103C-126F-4049-B697-785960945D08" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) In-Reply-To: Date: Tue, 7 May 2013 22:08:00 +0200 CC: PHP Developers Mailing List References: To: Sebastian Krebs X-Mailer: Apple Mail (2.1499) X-OriginalArrivalTime: 07 May 2013 20:08:03.0581 (UTC) FILETIME=[94CD3AD0:01CE4B5E] Subject: Re: [PHP-DEV] idea: letting the line number and file name be set via user_error From: bobwei9@hotmail.com (Bob Weinand) --Apple-Mail=_6171103C-126F-4049-B697-785960945D08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Am 7.5.2013 um 21:49 schrieb Sebastian Krebs : >=20 >=20 >=20 > 2013/5/7 Bob Weinand >=20 > Am 7.5.2013 um 21:07 schrieb Sebastian Krebs : >=20 >>=20 >>=20 >>=20 >> 2013/5/7 Bob Weinand >>=20 >> Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs : >>=20 >> > On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson = 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. >> >> >> >> > >> 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=E1cs >> > @Tyr43l - http://tyrael.hu >>=20 >> 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. >>=20 >> Still don't get it: >>=20 >> if ($errorCond) { >> trigger_error(); >> } >>=20 >> The error orginates from at most one line before... >=20 > 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? >=20 >> You debug today trigger_error's in libraries with putting a = debug_print_backtrace behind the trigger_error. >>=20 >> I use a debugger :X >=20 > 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...). >=20 > 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 :) >=20 >=20 >=20 > 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. >=20 >=20 > function foo1($a) { > foo2($a); > } >=20 > function foo2($a) { > foo3($a); > } >=20 > function foo3($a) { > foo4($a < 0 ? 0 : $a); > } >=20 > function foo4($a) { > foo5($a); > } >=20 > function foo5($a) { > if ($a =3D=3D 0) trigger_error('Foo'); > } >=20 > foo1(42); // OK > foo1(0); // Error > foo1(-42); // Error, but the wrong value now comes from foo3() >=20 >=20 > 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. >=20 >=20 >=20 > btw: Ever considered assert() to find such situations during = development? (Of course you should disable them on production) >=20 > Regards, > Sebastian > =20 > =20 >> 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...) >>=20 >> 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. >>=20 >> 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...) >>=20 >>=20 >> Bob >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >>=20 >>=20 >>=20 >>=20 >> --=20 >> github.com/KingCrunch=20 >=20 >=20 >=20 > Bob >=20 >=20 >=20 >=20 > --=20 > github.com/KingCrunch=20 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 --Apple-Mail=_6171103C-126F-4049-B697-785960945D08--