Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67003
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
MIME-Version: 1.0
Date: Mon, 8 Apr 2013 15:51:24 -0500
Message-ID: <CAEe4Dn-J5duO_1utp0RMPbVdU0fRnF3+Jz5ApOFCc_5hgcVqFw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=089e013c6ab097bbb104d9df9959
Subject: trigger_error() enhancements
From: zelnaga@gmail.com (Thomas Anderson)

--089e013c6ab097bbb104d9df9959
Content-Type: text/plain; charset=ISO-8859-1

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?

--089e013c6ab097bbb104d9df9959--