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.

PHP is not only available for many different operating systems, but it also offers native interfaces to a range of different Server APIs, or SAPIs in PHP lingo. The most common PHP SAPI is the Apache 1.3 module; others are CGI, CLI, the IIS filter, the embeddable version of PHP,and so on.

Some SAPIs offer PHP functions that are available only in that SAPI.
For example, the Apache 1.3 SAPI offers a function called apache_note() to
pass information to other Apache modules.

Table below shows some SAPI-specific functions.

Each database driver converts the error codes or error messages from the DBMS to a DB error code. These codes are represented as PHP constants. Here is a list of supported error codes given by examples of situations that causes them:

☞ DB_ERROR_ACCESS_VIOLATION. Missing privileges for a table, no read access
to file referenced by opaque parameters, or bad username or password.
☞ DB_ERROR_ALREADY_EXISTS. Table, sequence, procedure, view, trigger, or some
other condition already exists.
☞ DB_ERROR_CANNOT_CREATE. Cannot create table or file; the cause of problem
is outside the DBMS.
☞ DB_ERROR_CANNOT_DROP. Cannot drop table or delete file; the cause of problem
is outside the DBMS.
☞ DB_ERROR_CONNECT_FAILED. Could not establish database connection.
☞ DB_ERROR_CONSTRAINT. Foreign key does not exist, row contains foreign key
referenced by another table, and field constraints violated.
☞ DB_ERROR_CONSTRAINT_NOT_NULL. Field may not be NULL.