Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67004
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEe4Dn-J5duO_1utp0RMPbVdU0fRnF3+Jz5ApOFCc_5hgcVqFw@mail.gmail.com>
References: <CAEe4Dn-J5duO_1utp0RMPbVdU0fRnF3+Jz5ApOFCc_5hgcVqFw@mail.gmail.com>
Date: Tue, 9 Apr 2013 00:51:38 +0300
Message-ID: <CAGbiJu-n_4Odqdoc5NA0Eop+1kT=6Xf1paDMur7QTJXBzOf+Zw@mail.gmail.com>
To: Thomas Anderson <zelnaga@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] trigger_error() enhancements
From: dor.tchizik@gmail.com (Madara Uchiha)

What's wrong with set_error_handler()?
http://php.net/manual/en/function.set-error-handler.php

(Aside for the fact that any uncaught warning would be fatal).

On Mon, Apr 8, 2013 at 11:51 PM, Thomas Anderson <zelnaga@gmail.com> wrote:
> I was thinking it'd be useful if people could switch between throwing
> exceptions and displaying errors. If throw were a function and not a
> language construct one could do $function($error) where $function was a
> string equal to either 'trigger_error' or 'throw'. But alas that's not
> possible.
>
> In lieu of that it seems like it'd be useful if maybe a new error type
> constant could be added - E_USER_THROWABLE - that'd turn trigger_error into
> a throw. You wouldn't be able to use custom Exception classes in this
> instance but I think that'd be acceptable. ie. if you want more versatility
> use throw. If you just want to be able to switch between error's and thrown
> exceptions use trigger_error().
>
> Also, I think it'd be useful if developers could specificy which line
> number and file name the error (or exception) displays
>
> For example...  I was trying to implement support for
> stream_notification_callback in a custom stream wrapper. In my tests if you
> pass a non-callable string to the built-in ftp stream via, let's say,
> fopen(), you get an error saying "failed to call user notifier" on the
> fopen() line. But with custom stream wrappers the best you can do is to use
> trigger_error(). But that means that it's going to show not the line of the
> fopen() but instead the line of the trigger_error(). Which is of limited
> usefulness I'd say since the trigger_error() isn't where the error actually
> is.
>
> If a developer could control which line numbers and file names were
> displayed they could iterate through debug_backtrace() to get the actual
> line number they wanted to display.
>
> What are your thoughts?