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
