According to my knowledge, there are many ways to write a PHP application:
1. FastCGI : In this case, the interpreter is loaded during boot time; so the
application itself might also be compiled and loaded once.
2. mod_php : This is same as FastCGI?
3. CGI: The most usual way, there are some PHP code embedded into the web pages, and the PHP interpreter is loaded each time a PHP page is called.
4. application server : The application is compiled and loaded once and the application can either have its own web server, or use a web server as front end, and only handle its own part.

PEAR has its own error-reporting mechanism based around the principle of errors as types, and the ability to pass around errors as values. Many extras were built around this principle, to the point where PEAR errors almost function like a poor man’s (in this case, PHP 4 users’) exception.

Where PHP’s built-in error mechanism typically displays a message and a function returns false, a function returning a PEAR error gives an object back that is an instance of PEAR_Error or a subclass:

Several php.ini configuration settings control which errors should be displayed and how.

error_reporting (Integer)
This setting is the default error reporting for every script. The parameter
may be any of the constants listed here, E_ALL for everything or a logical
expression such as E_ALL & ~E_NOTICE (for everything except notices).

display_errors (Boolean)
This setting controls whether errors are displayed as part of PHP’s output.
It is set to On by default.

display_startup_errors (Boolean)
This setting controls whether errors are displayed during PHP startup.
It is set to Off by default and is meant for debugging C extensions.

error_prepend_string (String)
This string is displayed immediately before the error message when displayed
in the browser.

error_append_string (String)
This string is displayed immediately after the error message when displayed
in the browser.

track_errors (Boolean)

PHP errors are categorized by an error level ranging from notices to fatal errors. The error level tells you how serious the error is.Most errors may be caught with a custom error handler, but some are unrecoverable.

E_ERROR
This is a fatal, unrecoverable error. Examples are out-of-memory errors, uncaught exceptions, or class redeclarations.
E_WARNING
This is the most common type of error. It normally signals that something you tried doing went wrong. Typical examples are missing function parameters, a database you could not connect to, or division by zero.
E_PARSE
Parse errors occur during compilation, and force PHP to abort before execution. This means that if a file fails with a parse error, none of it will be executed.
E_STRICT
This error level is the only one not included in the E_ALL constant. The reason for this is to make transition from PHP 4 to PHP 5 easier; you can still
run PHP 4 code in PHP 5.
E_NOTICE

Once code is up and running, non-fatal runtime errors are the most common type of error in PHP. Runtime refers to errors that occur during execution of the code, which are not usually programming errors but caused factors outside PHP itself, such as disk or network operations or database calls.

PHP has an error-reporting mechanism that is used for all errors triggered inside PHP itself, either during compilation of the script or when executing a built-in function. You can use this error-reporting mechanism from a script as well, although there are more powerful ways of reporting errors (such as exceptions).

Even perfectly good code may produce runtime errors, so everyone has to deal with them in one way or another.