NYCPHP Meetup

[Dan Cech]

On 6/23/2011 11:04 PM, Gary Mort wrote:
> I'm confused on the difference in common PHP usage between when one
> should use an exception and when one should use an error.

I usually set up a custom error handler to report internal problems via 
a back-channel (email, http to a tracking server, etc), and use 
Exceptions or other error reporting methods (PEAR_Error, etc) for 
returning error information destined for the user.

A pseudo-code example:

function do_something()
{
   // do something in the database
   $result = db_query(<some sql>);

   // if the query fails
   if (!$result) {
     // report the technical details via back channel
     trigger_error(db_error_details());

     // return a descriptive error to the user
     throw new Exception('Couldn't do something, contact support');
   }

   // use $result to do something

   return true
}

Of course there are innumerable ways to skin a cat, but this approach 
has worked out ok for me, and it means that I get back-channel 
notifications for all errors (php notices, etc).

> Most of my confusion comes from the fact that the way both Exceptions
> and Errors are handled and generated in PHP has changed over the years,
> with each one being used at times incorrectly because the other did not
> have all the functionality needed for particular usages.
>
> So, to review what my understanding is as of PHP 5.3:
>
> When an error is generated in PHP, there are a number of pre-defined
> types of errors:
> http://www.php.net/manual/en/errorfunc.constants.php
>
> What are especially useful for programmers is differentiating between:
> Depreciated, Notice, Warning,&  Error.

Firstly, http://en.wikipedia.org/wiki/Deprecation

> As of PHP 5.3 all of the above error levels have both a PHP error level
> and a "user" error level.  An example of the difference between them
> could be that when running a program that utilizes a PHP framework, if
> at some point in the code there is a call to the split() function - the
> program will execute correctly, however a depreciated error will be
> generated and if such errors are logged, periodic review of logfiles
> will give programmers a heads up that they have to recode part of the
> program.   Wheras if that framework defines it's own internal functions,
> and one function is slated to be removed, good programming practice
> would be for the framework authors to generate a user_depreciated error
> notice - which can be used in the same manner to update code using that
> framework.
>
> When user errors are generated in PHP, the program may or may not abort
> when the error is generated.  It may or may not log the error message to
> a file or some other method.  All of this depends primarily on how the
> PHP instance is configured.

Yes, though by setting a custom error handler you can take control of 
almost all of the errors (those excluded are listed here 
http://us3.php.net/set_error_handler) and process them however you see fit.

> This makes user errors great for providing information about potential
> problems with the code when you are not sure whether or not the error
> should result in the program aborting or just noting a transitory problem.

Yes, except that it is a pretty blunt instrument.  You can either return 
to the program flow where it left off, or completely exit.

> Exceptions can do most of the things user errors are used for, but one
> thing they cannot do is continue executing from the point of the
> exception being thrown.  Once thrown, the block of code being executed
> is aborted and the path of coding goes to the exception handler
> instead.   This could be used to generate an error message of some sort,
> log a problem, etc.

Not entirely true, but the code needs to be aware and have provisions to 
catch the Exception, whereupon it can take whatever action is necessary.

> As an example, consider a web page where we have a common header, a
> common footer, and then the main section of the web page.  For a
> particular url, the data being displayed in the main section is
> restricted to authorized individuals.
>
> Error handling: the page can be completely generated by one function.
> First the header is sent, then the authorization for the main section is
> checked - if it fails, an error can be generated and an unauthorized
> message generated for display, if it succeeds the data can be generated
> - then the footer is sent.  The user of the application can decide that
> they want to do something different[lock the account, abort handling,
> call the cops] by creating their own error handler function and calling
> it before they call the third party code.

Typically you'd want to do at least the access checks before you output 
anything to the client.

> Exception handling: The code needs to be much more object oriented.  For
> the main body of code, you might have an object where you call a
> generate header, generate content, and generate footer method.  In the
> generate content method, you would have to have a try block around the
> authorization check and content generation, and if authorization fails
> throw an exception.  You would also need to catch the exception and in
> the exception handling generate the error message to display for the user.

If you want to duplicate the same behavior as a custom error handler you 
can implement a custom exception handler 
(http://php.net/set_exception_handler) and perform the same sort of 
logic as in a custom error handler, with the advantage that code can 
trap and handle its own exceptions, only unhandled exceptions will 
bubble up to your handler.

> Here it can be much harder to override the default manner in which the
> exception is handled and add your own method.

See above.

> So what I'm curious regarding is how are these 2 methods used in
> practice today, as opposed to theory.  Especially when considering the
> use of frameworks where you don't expect a single team of programmers to
> be writing all the code -but rather you are building on an existing
> framework which can generate it's own errors and exceptions.

To my way of thinking these 2 systems are complementary, and as outlined 
above typically use them side-by-side for different purposes: 
trigger_error & php-generated errors for development/debugging and 
exceptions or other error return mechanisms for communicating errors 
back to the calling code and eventually to the client.

Dan