Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67355
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALtuQzAkUzazSaFaxY_iCrBHRgdpdRyq04rv5mJDZhhfLtD+aA@mail.gmail.com>
References: <CAEe4Dn8qHRQnyVdsFGUdsKMLfG3t3R9tJuryfUdCKF-EvBaVvg@mail.gmail.com>
	<CAH-PCH69g-Vwi0_M-2A=CRFMDPNMEXzGGj=rjoDEGNWxViXK1w@mail.gmail.com>
	<BLU0-SMTP164094802A24ECF73FFADB2E2BA0@phx.gbl>
	<CALtuQzC3qBiGvZnWUZX0JenaBow3Cqmv6thEvAEF9iemta_Vqg@mail.gmail.com>
	<BLU0-SMTP466AE7EAE40CDD61E342281E2BA0@phx.gbl>
	<CALtuQzAkUzazSaFaxY_iCrBHRgdpdRyq04rv5mJDZhhfLtD+aA@mail.gmail.com>
Date: Tue, 7 May 2013 15:02:37 -0500
Message-ID: <CAEe4Dn8VuN78YO9LHOQO=TwObyLoV2w+QN0Aqz3UghutRkRupA@mail.gmail.com>
To: Sebastian Krebs <krebs.seb@gmail.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, 
	PHP List Developers Mailing <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7beb986e8412aa04dc264ce0
Subject: Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
From: zelnaga@gmail.com (Thomas Anderson)

--047d7beb986e8412aa04dc264ce0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, May 7, 2013 at 2:49 PM, Sebastian Krebs <krebs.seb@gmail.com> wrote=
:

> 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" (i=
e.
> >> the
> >> >> line that the call to the test() function is made).
> >> >>
> >> >> If the displayed line numbers could be controlled by user_error the=
n
> >> >> 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/mo=
st
> >> > people would look up the file:line number and would be surprised tha=
t
> >> 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 (y=
ou
> >> 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
> >>
> >> 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 productio=
n
> > 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 lin=
e,
> 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 =3D=3D 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.

--047d7beb986e8412aa04dc264ce0--