Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 4:30 PM, Sebastian Krebs wrote:
> 2013/5/7 Bob Weinand
>
> >
> > Am 7.5.2013 um 22:11 schrieb Stas Malyshev :
> >
> > > 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
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> > 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.
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 3:38 PM, Stas Malyshev wrote: > Hi! > > > So the error messages your library produces have the same consistent > > look and feel to them that PHP's errors do? > > While it may be nice, I don't think it is worth changing the PHP API > for. Error messages have very defined api, which has the place in the > source where they were actually produced. > So just redefine the API lol. ie. make it so trigger_error has this as its function definition: bool trigger_error ( string $error_msg [, int $error_type = E_USER_NOTICE [, string $errfile = __FILE__ [, int $errnum = __LINE__ ]]] ) > > > Besides, keeping in mind the KISS "keep it simple stupid" principal > > gratuitous information should probably be hidden away. I mean if it's > > not going to help anyone then the only thing left for it to do is > > potentially confuse people. And why risk that? > > The place where the error is produced is definitely helpful. Now, it may > not be *all* the information you need, but error messages are simple > things, they are not meant to replace debugger with full backtrace and > stack inspection. I don't think it needs added complications just to > have some library messages look a little nicer. > In any case, one can install custom error handler which would format > messages for user errors differently, if desired. > > You shouldn't need to load up a debugger with a full backtrace and stack inspection to figure out (from my previous example) that you had a divide by 0 error. That said I will concede the "look a little nicer" point. I guess, in my mind, it's really just a matter of how many code changes would be required. If 10,000 lines of code in PHP would have to be changed... it's not worth it. If all you'd be modifying are two lines of code... doesn't seem like such a big deal to me. Besides, what if a program already has an error handler defined?
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 3:14 PM, Stas Malyshev wrote:
> Hi!
>
> > 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.
>
> If you need additional information to accompany the error, why not add
> it to the "whatever" string? This way you can control whatever is
> displayed.
>
>
So the error messages your library produces have the same consistent look
and feel to them that PHP's errors do?
Besides, keeping in mind the KISS "keep it simple stupid" principal
gratuitous information should probably be hidden away. I mean if it's not
going to help anyone then the only thing left for it to do is potentially
confuse people. And why risk that?
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 2:49 PM, Sebastian Krebs wrote:
> 2013/5/7 Bob Weinand
>
> >
> > Am 7.5.2013 um 21:07 schrieb Sebastian Krebs :
> >
> >
> >
> >
> > 2013/5/7 Bob Weinand
> >
> >>
> >> Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs :
> >>
> >> > 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á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.
Re: [PHP-DEV] idea: implement a Comparable interface
On Tue, May 7, 2013 at 1:05 PM, Nikita Popov wrote: > On Tue, May 7, 2013 at 6:17 PM, Thomas Anderson wrote: > >> It'd be nice if, when doing $objA > $objB, that that'd invoke >> $objA->__compareTo($objB) or something, much like Java's Comparable >> interface. >> > > Do you have examples of what this would be useful for? The two things that > come to mind are DateTime (which can do this anyway as it's an internal > class) and classes for bignums or something like that (which are probably > also better implemented internally). So I'm not sure how much use there is > for this. > bignum PHP class: http://phpseclib.sourceforge.net/math/intro.html Per the benchmarks it's internal implementation (without OpenSSL) is faster than BCMath is in 5.4 lol. Not sure which OS the test was ran on. That's the only use case I can come up with off the top of my head but that's more than I can come up with for Iterator atm lol.
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 2:04 PM, Sebastian Krebs wrote:
>
>
>
> 2013/5/7 Thomas Anderson
>
>> 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).
>>
>
> Something I don't understand: You call test() in line 7 and line triggers
> the error, so in fact it is _really_ line 3, that causes the message. So
> why should it display "line 7", when it is obvious the wrong line?
>
>
I thought half the point of OOP was to abstract away the internals and as
is the error messages don't make much sense unless you *do* consider the
internals.
Like let's say you have a bignum library and you're doing
$fifteen->divide($zero) on line 5 of test.php. Seems to me that it'd be
more useful to say "error: division by zero" on line 5 of test.php instead
of line line xx of file yy. It's like...
"ooh - let me try to find where I'm doing division by zero. Let me to line
xx of file yy that I didn't even write and don't know a thing about. ok...
so it looks like that's in the private _helper_function(). And
_helper_function() is called by 15x other public functions. I give up!"
As an end user of a library you shouldn't have to actually look into that
library if you're the one who's not properly handling something.
[PHP-DEV] idea: implement a Comparable interface
It'd be nice if, when doing $objA > $objB, that that'd invoke $objA->__compareTo($objB) or something, much like Java's Comparable interface.
[PHP-DEV] idea: letting the line number and file name be set via user_error
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.
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.
Re: [PHP-DEV] trigger_error() enhancements
That only addresses my first idea, however, one problem with it I see is that there's not as much fine tuned granularity with it. What if, for error produced by some functions, you wanted to display an HTML page showing the error and other errors you just wanted to silently log it to the DB or something. With catching you can just catch each function's errors and handle them as you see fit on a one off basis without unilaterally effecting how all errors are handled. Also, I think catching makes for more "linear" easier to read code. Or at least it can. You want to know how the error is handled? Just scroll down a line or two to the catch block. With error handling you can't scroll down a line or two - you have to go to the top, to the bottom, to another file, or whatever. Certainly it's possible to write hard to read code with try / catch blocks too (like if you have the whole file in a giant try block) but with set_error_handler() it's not just possible - it's almost guaranteed. On Mon, Apr 8, 2013 at 4:51 PM, Madara Uchiha wrote: > What's wrong with set_error_handler()? > http://php.net/manual/en/function.set-error-handler.php > > (Aside for the fact that any uncaught warning would be fatal). > > On Mon, Apr 8, 2013 at 11:51 PM, Thomas Anderson > wrote: > > I was thinking it'd be useful if people could switch between throwing > > exceptions and displaying errors. If throw were a function and not a > > language construct one could do $function($error) where $function was a > > string equal to either 'trigger_error' or 'throw'. But alas that's not > > possible. > > > > In lieu of that it seems like it'd be useful if maybe a new error type > > constant could be added - E_USER_THROWABLE - that'd turn trigger_error > into > > a throw. You wouldn't be able to use custom Exception classes in this > > instance but I think that'd be acceptable. ie. if you want more > versatility > > use throw. If you just want to be able to switch between error's and > thrown > > exceptions use trigger_error(). > > > > Also, I think it'd be useful if developers could specificy which line > > number and file name the error (or exception) displays > > > > For example... I was trying to implement support for > > stream_notification_callback in a custom stream wrapper. In my tests if > you > > pass a non-callable string to the built-in ftp stream via, let's say, > > fopen(), you get an error saying "failed to call user notifier" on the > > fopen() line. But with custom stream wrappers the best you can do is to > use > > trigger_error(). But that means that it's going to show not the line of > the > > fopen() but instead the line of the trigger_error(). Which is of limited > > usefulness I'd say since the trigger_error() isn't where the error > actually > > is. > > > > If a developer could control which line numbers and file names were > > displayed they could iterate through debug_backtrace() to get the actual > > line number they wanted to display. > > > > What are your thoughts? >
[PHP-DEV] trigger_error() enhancements
I was thinking it'd be useful if people could switch between throwing exceptions and displaying errors. If throw were a function and not a language construct one could do $function($error) where $function was a string equal to either 'trigger_error' or 'throw'. But alas that's not possible. In lieu of that it seems like it'd be useful if maybe a new error type constant could be added - E_USER_THROWABLE - that'd turn trigger_error into a throw. You wouldn't be able to use custom Exception classes in this instance but I think that'd be acceptable. ie. if you want more versatility use throw. If you just want to be able to switch between error's and thrown exceptions use trigger_error(). Also, I think it'd be useful if developers could specificy which line number and file name the error (or exception) displays For example... I was trying to implement support for stream_notification_callback in a custom stream wrapper. In my tests if you pass a non-callable string to the built-in ftp stream via, let's say, fopen(), you get an error saying "failed to call user notifier" on the fopen() line. But with custom stream wrappers the best you can do is to use trigger_error(). But that means that it's going to show not the line of the fopen() but instead the line of the trigger_error(). Which is of limited usefulness I'd say since the trigger_error() isn't where the error actually is. If a developer could control which line numbers and file names were displayed they could iterate through debug_backtrace() to get the actual line number they wanted to display. What are your thoughts?
Re: [PHP-DEV] idea: add wrapper support to mysqli_connect
On Wed, Mar 13, 2013 at 3:37 PM, Rasmus Lerdorf wrote: > On 03/13/2013 12:08 PM, Thomas Anderson wrote: >> Instead of passing localhost to mysqli_connect as the $host parameter >> I think it'd be useful if you could pass something like >> ssh2.tunnel://user:p...@example.com:22/192.168.0.1:14 to it as well. >> >> The main advantage I see of doing that is that you could tunnel >> through SSH2, through SOCKS, through HTTP CONNECT, etc, a lot more >> easily than you currently can. Like you could have an SSH connection >> re-created every time a PHP script is called and a tunnel dynamically >> made instead of having a persistent tunnel created with autossh or >> whatever. >> >> And even if SSH2 / SOCKS / CONNECT don't exist as built-in wrappers >> custom stream wrappers could be made. This would additionally make it >> easy for people to examine the underpinnings of MySQL. Instead of >> intercepting the packets the MySQL client sends out and placing them >> into an SSH tunnel or whatever one could just dump them to a log file >> to better understand how MySQL clients work internally. > > Instead of adding all that gear to PHP itself, wouldn't it make more > sense to just use something like autossh to maintain your ssh tunnel and > have PHP connect to your tunnel endpoint? mysqli_connect() in PHP is > just a thin wrapper on top of the underlying library. Oh - I didn't know that. I thought (hoped) it might have been like a two second code change lol. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] idea: add wrapper support to mysqli_connect
Instead of passing localhost to mysqli_connect as the $host parameter I think it'd be useful if you could pass something like ssh2.tunnel://user:p...@example.com:22/192.168.0.1:14 to it as well. The main advantage I see of doing that is that you could tunnel through SSH2, through SOCKS, through HTTP CONNECT, etc, a lot more easily than you currently can. Like you could have an SSH connection re-created every time a PHP script is called and a tunnel dynamically made instead of having a persistent tunnel created with autossh or whatever. And even if SSH2 / SOCKS / CONNECT don't exist as built-in wrappers custom stream wrappers could be made. This would additionally make it easy for people to examine the underpinnings of MySQL. Instead of intercepting the packets the MySQL client sends out and placing them into an SSH tunnel or whatever one could just dump them to a log file to better understand how MySQL clients work internally. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
