idea: letting the line number and file name be set via user_error View as Markdown

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.

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.

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:

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

--
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

2013/5/7 Bob Weinand bobwei9@hotmail.com

Am 7.5.2013 um 22:11 schrieb Stas Malyshev smalyshev@sugarcrm.com:

Hi!

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

Why not use a debugger to debug? Debuggers have backtrace tools.

(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...)

If you need additional information in the notice, you can always add it
to the text of the notice.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--

nothing against the debugger, but it'd be something really time saving to
see the entry point instantly instead of having to use the debugger
first...

And yes, I can add it to the text (I can even add a function between
which
analyses the backtrace first), but I think we need more useful (= more
information) error throwing in PHP?

How do you want to find out, which call initially set the invalid values?
Is this even (reliable) possible? I've given an example, that it isn't that
trivial.
So even if you have the two additional parameters, what will you set there
(except maybe something like "LINE-4", which is as trivial as useless)?
With this in mind: How do you think the additional parameters can help?

Another example

function foo() {
return 0;
}

function bar($a) {
div($a);
}

function div($a) {
if ($a == 0) trigger_error('');
}

div(bar(foo()));

Which line should the message report now:

• bar() because it calls div()?
• or foo() because it is the function, that returns the invalid value, that
  is used later? But 0 is maybe a valid return value for foo()?
• or div(bar(foo()));, but how to find out, that foo() really returned
  the invalid value?

Like in my other example you can report any file and line you want and
which is maybe/probably involved, but in most if not all cases it doesn't
prevent you from debugging.

PHP wouldn't auto-magically be figuring it out - the person writing the PHP
code would be the one to figure it out.

If you wrote a bigint library and of those three functions the only one you
wrote was div() then presumably you - as the author of that bigint library

• would make it show the line number on which the div() was called. Maybe
  bar() and foo() trigger errors as well.. who knows. Just because you have
  everything on the same line doesn't mean you can't have multiple errors on
  the same line. That's really the business of the end-user using the bigint
  lib.

And if you, as a PHP developer, wrote all three functions - foo(), bar()
and div()... it's up to you which one shows up as being the call that
caused the error. PHP shouldn't be trying to auto-magically figure it out
nor was that my proposal.

It's like... if someone writes a callback function for preg_replace() the
person who wrote that function is going to be the one who decides what
subpattern - if any - that function is going to look at. I don't know why
anyone would expect PHP to auto-magically figure it out.