Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67352
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.182 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAEe4Dn-t+sMqnQ7y=vFc2D79MAbfiWEf8Rdf=fbigNMk6hOtLw@mail.gmail.com>
References: <CAEe4Dn8qHRQnyVdsFGUdsKMLfG3t3R9tJuryfUdCKF-EvBaVvg@mail.gmail.com>
 <CALtuQzCsHkV8TgHL4mjTtdJOVD+dTKAybLB2OwncbxiSJBkhKw@mail.gmail.com> <CAEe4Dn-t+sMqnQ7y=vFc2D79MAbfiWEf8Rdf=fbigNMk6hOtLw@mail.gmail.com>
Date: Tue, 7 May 2013 12:32:21 -0700
Message-ID: <CADajX4CZjc_oyHN-ucOp3M=WRzgRc6jEhteaEZGWoTAJ86iEig@mail.gmail.com>
To: Thomas Anderson <zelnaga@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
From: aharvey@php.net (Adam Harvey)

On 7 May 2013 12:24, Thomas Anderson <zelnaga@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