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
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
