Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67364
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51896633.7000206@sugarcrm.com>
References: <CAEe4Dn8qHRQnyVdsFGUdsKMLfG3t3R9tJuryfUdCKF-EvBaVvg@mail.gmail.com>
	<51896088.4070907@sugarcrm.com>
	<CAEe4Dn8=0PGPt20oewFFQxrvvgd=mNU+Ki90H097nX4Ai8H-RQ@mail.gmail.com>
	<51896633.7000206@sugarcrm.com>
Date: Tue, 7 May 2013 15:46:29 -0500
Message-ID: <CAEe4Dn_SxQpSzz-p2shm0TBrv7aVWoekU2n3MYSVzrESAUDoQw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7beb986e6a783b04dc26e9d8
Subject: Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
From: zelnaga@gmail.com (Thomas Anderson)

--047d7beb986e6a783b04dc26e9d8
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 7, 2013 at 3:38 PM, Stas Malyshev <smalyshev@sugarcrm.com>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?

--047d7beb986e6a783b04dc26e9d8--