views:

89

answers:

2

I'm new to PHP so I apologize if this seems silly. I've searched around and couldn't find anything that explained specifically what I'm looking for.

Ultimately I have two goals.

  1. In production, when an unexpected error occurs, show the user a default "oops" page.
  2. When an expected error occurs, handle it without PHP dying.

My mental model of PHP error handling is spotty enough that I can't move forward with any confidence and I haven't been able to find any good documentation about the process.

To give some contrived examples.

  1. user makes a request, connection to the DB fails, we display an oops message.
  2. user makes a request, script doesn't doesn't parse correctly, we display an oops message.
  3. user makes a request, we query the DB with an update using optimistic locking. It fails, so we inform the user that the object has been updated.

I think most of my confusion is surrounding what errors result in the script dying and what errors do not (using the default handler), and when the script dies, how do we gracefully inform the user?

Also, do any of the standard php functions/objects use exceptions? If I choose to handle exceptions in more of a C style I'm not going to be surprised at any point am I? Is this going to change in PHP6? If so I'll put forth the effort to paper over the differences between using c style and exceptions, but if not, I'd rather just use the c style consistently throughout PHP5. That is not a problem I am interested in solving unless I absolutely need to.

edit: I just realized the content doesn't quite match the title. I would like to know, when an error occurs, what is the logic flow for PHP? This way I can better understand how to go about achieving my goals with respect to error handling in PHP.

A: 

Exceptions are well integrated into PHP5. They have the same try/catch syntax as Java/C++ exceptions. Use them when an expected error occurs.

If you want to show a custom "oops" page you can use set_exception_handler in combination with trigger_error. For more tips consider this link.

mre
Which doesn't work in the case of a parse error.This is not what I'm looking for.
Fred
+2  A: 

most of PHP's built in tuff triggers errors that you can't really deal with in a default setup.

You can however workaround this by setting up a custom error handler and throwing an exception instead of the error. (PHP will, when possible, run your handler before handling the error internally, so you can actually catch Exceptions in the normal way.)

I've written a bunch of code you could use for this situation in my answer here: http://stackoverflow.com/questions/841500/php-exceptions-vs-errors

If php can't actually parse your file you're pretty much screwed, php will crash pretty hard under most circumstances where it can't parse a file. Though you could try writing your own include function that eval's a file before including it and just skips if eval failed. You'll need to be sure you can basically trust the files though.

Kris
When will PHP's internal error handler kill the script?
Fred
when an unrecoverable error is triggered (E_ERROR) _and_ there's no user defined handler that handles it gracefully. E_PARSE kills the interpreter if it is triggered in the current line of execution (so not within some function you're not actually using). see http://www.php.net/manual/en/errorfunc.constants.php for more info.
Kris
Thank you Kris, that was exactly what I was looking for. I had attempted to find that information earlier and failed.It sounds to me like I could set up a handler for E_ERROR and have it go to an oops page, and then use trigger_error() fire off another handler for E_USER_ERROR that would also go to the "oops" page for other unrecoverable conditions such as a failing to connect to the DB.According to the documentation, E_USER_ERROR is "just like E_ERROR". If the default error handler gets it, I assume it will kill the script, just like E_ERROR?
Fred
Also, 1 last question (I'll put the results back in the original article).If I log the errors with the function "error_log" will it log them to the same place they would have been logged if the default error handler had gotten them? If not, what function do I need to use in order to do so? I don't like the idea of having multiple error logging mechanisms, and I would like to avoid catching *all* errors just to log them for possible performance reasons (let me know if you think that concern is off base).
Fred
according to http://php.net/manual/en/function.error-log.php the message gets logged to the systems' default log location (so whatever is set in the server configuration) if you don't override the destination in the call.
Kris