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. On Mon, Apr 8, 2013 at 4:51 PM, Madara Uchiha <dor.tchi...@gmail.com> wrote: > 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 <zeln...@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? >
