Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67339
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.101 as permitted sender)
Message-ID: <BLU0-SMTP164094802A24ECF73FFADB2E2BA0@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
In-Reply-To: <CAH-PCH69g-Vwi0_M-2A=CRFMDPNMEXzGGj=rjoDEGNWxViXK1w@mail.gmail.com>
Date: Tue, 7 May 2013 19:14:35 +0200
CC: zelnaga@gmail.com,
 PHP Mailing List Developers <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <CAEe4Dn8qHRQnyVdsFGUdsKMLfG3t3R9tJuryfUdCKF-EvBaVvg@mail.gmail.com> <CAH-PCH69g-Vwi0_M-2A=CRFMDPNMEXzGGj=rjoDEGNWxViXK1w@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Subject: Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
From: bobwei9@hotmail.com (Bob Weinand)


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:
>=20
>> 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.
>>=20
>> <?php
>> function test() {
>>    user_error('whatever');
>> }
>>=20
>> test();
>> ?>
>>=20
>> 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).
>>=20
>> 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.
>>=20
>=20
> 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..
>=20
> I didn't like this proposal.
>=20
> --=20
> 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. You debug today trigger_error's in libraries with =
putting a debug_print_backtrace behind the trigger_error.
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=