[phplib] unified error handling From: Layne Weathers (layne <email protected>)
Date: 07/23/01

One item that needs to be implemented is a central error handling class.
I've done a little work on this, but nothing that I would want anyone to
look at yet.

Problems with the current implementation:
1. inconsistent error handling between classes
    a. auth echoes messages directly, no error handling function or
variables
    b. db_mysql has error handling functions and variables, echoes
"</td></tr></table>" and then the message
2. the error messages currently given are targeted at the web developer and
are not suitable for viewing by normal web site users

I will try to describe the basic aspects of the error class I am
envisioning. There are other thoughts in my head on this and I'm sure there
are things I haven't thought of. My intent is to see if others have
addressed this issue on their own, refine the ideas communally, and
hopefully start the process of implementation.

Errors are either fatal (e.g. not connecting to a database) or not fatal
(e.g. calling next_record() with no results) and either visible (i.e.
printed for normal users) or invisible (i.e. logged, commented in html,
mailed to admin, etc.); a debugging mode could display all errors
encountered while building a page. Errors for individual functions are
invisible but may trigger a visible generalized class error that is actually
intelligible to the average user.

A global error object is initialized in prepend.php. Every class' error()
function calls the global error object which then logs the errors, organizes
them by page request (perhaps session id as well), and displays them if
applicable. The display of errors would be extended by personal preference
in local.inc - I may prefer to throw the errors through a template while
others may echo them directly to the page.

The logging of errors would most likely require a functioning database class
(and perhaps other classes as well) so each class that is used by the error
class would need a per-instance switch to disable error handling. The last
thing we want is a database not connecting which sends an error which tries
to log to the database but can't connect so it sends an error ad infinitum.

I would create an interface to view and delete logged errors - I would
monitor the errors during the development of a site and then set up a daily
or weekly email notification of errors once the development process ends.

Because errors would be viewable outside of their original context, the page
on which the errors occurred would need to be recorded along with any post,
get and cookie vars.

Layne Weathers
Ifworld, Inc. 

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>