It however gets very messy for managing program flow errors, having to use @ and the $error_msg variable dont make for very readable code. Exceptions (PHP5) or PEAR::Error (PHP4) are better suited to that.

Basically every error should be thrown, no matter whether it’s fatal or not. This way it’s the code’s client’s decision if and where to catch it, wheter it’s fatal and what to do with it.

Who knows, maybe your mysql connection error could be recovered from by using an alternate server. Too bad the application would already be stone-dead after the first attempt. :)

Then again you could use E_USER_WARNING or E_USER_NOTICE but without a custom error handler your client code would miss those errors.

In my opinion trigger_error only goes well with very simple functional applications.

When using PHP 5 you should definately use exceptions instead of killing your application

For every exception that is thrown, it either has to be caught, or generate an uncaught exception error.

If it is caught, you still have the problem of deciding what to do when the error is caught. Wouldn’t you agree?

Obviously, if you can recover from the situation you wouldn’t have to exit or use trigger_error. However, if it’s unrecoverable, what do you do when you catch the exception? Do you display an error message to the screen or do you log the error? Exception handling doesn’t define what to do when an exception is caught, it just provides a way of catching an exception. If you are on a live server, you don’t want to display a diagnostic error message, which will reveal a lot about your application, to the public. You want it to be quietly logged. However, if you are on a testing server, then having diagnostic information shown on screen is desirable.

Consider the following code:

try { $error = 'Always throw this error'; throw new Exception($error); // Code following an exception is not executed. echo 'Never executed'; } catch (Exception $e) { echo 'Caught exception: ', $e->getMessage(), "\n"; }

When the exception is caught, all that is done is an error message is displayed on screen. If we replaced ‘echo’ with ‘trigger_error’, then we could use PHP’s error handling to decide what to do with the error. It’s easy to define custom error handling with ’set_error_handler’.

When the exception is caught, all that is done is an error message is displayed on screen

In your trivial example yes

The power of exceptions is, as Maarten Manders said, to be able to recover from the exceptional behaviour that has occurred. To use his example, you can catch whatever exception is thrown when a connection can’t be established to the MySQL server. To recover from the exception you could use a cached version of the data, connect to another server or something else. However, if you know your application can’t recover after a failed attempt to connect to the MySQL server then you can leave the exception to be caught with a custom exception handler (see set_exception_handler()) and log it, email it, show a general message or a debug page or anything else

Sean :)

yours, Marcus