[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. ?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.
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
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
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
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
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Thomas Anderson zeln...@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). 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? 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. -- github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Bob Weinand bobw...@hotmail.com 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. Still don't get it: if ($errorCond) { trigger_error(); } The error orginates from at most one line before... You debug today trigger_error's in libraries with putting a debug_print_backtrace behind the trigger_error. I use a debugger :X 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 -- github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com: 2013/5/7 Bob Weinand bobw...@hotmail.com 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. 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...). 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 -- github.com/KingCrunch Bob
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 krebs@gmail.com wrote: 2013/5/7 Thomas Anderson zeln...@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). 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.
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On 7 May 2013 12:24, Thomas Anderson zeln...@gmail.com wrote: 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! Sure, but in practice, that's why most development environments provide backtraces on error or uncaught exception, whether through something like XDebug or via a call to debug_print_backtrace() in the error/exception handler. That gives you both the specific information you want (the last file and line of non-library code that called into the erroneous function(s)) and all the additional context you might need. As Ferenc said, I also don't understand how you'd get the fake file and line numbers for the trigger_error() call without guesswork or going back up through the backtrace anyway, which is something that doesn't belong in non-handler code, IMO. 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. I agree, but this is already a solved problem in PHP. All the tools needed are there. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Thomas Anderson zeln...@gmail.com On Tue, May 7, 2013 at 2:04 PM, Sebastian Krebs krebs@gmail.comwrote: 2013/5/7 Thomas Anderson zeln...@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). 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. Part of OOP are Exceptions. 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... Somebody else already mentioned, that he wants to trigger notices at first, but here the application is broken. So (see above) Exception is more apropriate. 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! You should have validated the input parameters before every of the 15 calls. 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. In an ideal world you are propably right, but this is rarely possible/useful. -- github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Bob Weinand bobw...@hotmail.com Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com: 2013/5/7 Bob Weinand bobw...@hotmail.com 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch Bob -- github.com/KingCrunch
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 krebs@gmail.com wrote: 2013/5/7 Bob Weinand bobw...@hotmail.com Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com: 2013/5/7 Bob Weinand bobw...@hotmail.com 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. 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: letting the line number and file name be set via user_error
Am 7.5.2013 um 21:49 schrieb Sebastian Krebs krebs@gmail.com: 2013/5/7 Bob Weinand bobw...@hotmail.com Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com: 2013/5/7 Bob Weinand bobw...@hotmail.com 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch Bob -- github.com/KingCrunch My error messages look like: Notice:
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
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
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
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. -- 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
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 smalys...@sugarcrm.comwrote: 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
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. 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. -- 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
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 smalys...@sugarcrm.comwrote: 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
Am 7.5.2013 um 22:11 schrieb Stas Malyshev smalys...@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 -- 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? Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Bob Weinand bobw...@hotmail.com Am 7.5.2013 um 22:11 schrieb Stas Malyshev smalys...@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 -- 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. Regards, Sebastian Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
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 krebs@gmail.com wrote: 2013/5/7 Bob Weinand bobw...@hotmail.com Am 7.5.2013 um 22:11 schrieb Stas Malyshev smalys...@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 -- 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.