trigger_error() enhancements

That only addresses my first idea, however, one problem with it I see is
that there's not as much fine tuned granularity with it. What if, for error
produced by some functions, you wanted to display an HTML page showing the
error and other errors you just wanted to silently log it to the DB or
something. With catching you can just catch each function's errors and
handle them as you see fit on a one off basis without unilaterally
effecting how all errors are handled.

Also, I think catching makes for more "linear" easier to read code. Or at
least it can. You want to know how the error is handled? Just scroll down a
line or two to the catch block. With error handling you can't scroll down a
line or two - you have to go to the top, to the bottom, to another file, or
whatever.

Certainly it's possible to write hard to read code with try / catch blocks
too (like if you have the whole file in a giant try block) but with
set_error_handler() it's not just possible - it's almost guaranteed.

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?