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. 
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to