Re: idea: letting the line number and file name be set via user_error

2013/5/7 Thomas Anderson <zelnaga@gmail.com> > > > On Tue, May 7, 2013 at 2:04 PM, Sebastian Krebs <krebs.seb@gmail.com>wrote: > >> >> >> >> 2013/5/7 Thomas Anderson <zelnaga@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