[nycphp-talk] NEW PHundamentals Question - Error Handling
Tim Gales
tgales at tgaconnect.com
Mon May 10 10:29:25 EDT 2004
> Can you narrow this down in the context of PHP programming?
> Not everything may be relevant (or maybe it is?) in the context of
> building/programming a website.
>
> Jeff
I guess I was jumping ahead a bit in
thinking it might be nice to develop an
error handling class structure in the article
to show how error handling decisions might be
implemented.
The granddaddy class would be rather
abstract. It would have member variables
correlating to the five W's.
The 'abstract' class would be extended to
take care of more specific situations.
But in general all the descendant classes would have
inherited methods for dealing with felonies,
misdemeanors, and ethical infractions and
perhaps a method for granting immunity (especially
on a 'quid pro quo' basis for more information
leading to an indictment of other guilty routines)
The methods would be just overloaded -- whoops,
pardon me, I mean extended to deal with the specifics
of each of the more specialized classes
(and their environments).
Maybe there could be classes for Linux, Windows,
HP-UX, BSD, etc. directly inheriting from
the base class. And an Apache class and maybe a an
IIS class.
Towards the end of the line you might have
a PHP error class and an Application error class.
Something like this:
Err_class
Err_Linux
Err_Apache
Err_PHP
Err_App_Framework
Err_demo (the class in the article)
You could make a simplified framework (really
just for demonstrating the ideas in the article)
and extend the framework class to handle
things that can go wrong with some mini-app.
(again the mini-app using the Err_demo class)
would exist mainly to demonstrate the ideas in the article --
but might indicate how you could do something useful)
This kind of article would be a major departure
from most articles that often include
comments in the code saying something like
// handle exceptions here...
Further, regular readers of PHundamentals
could become familiar with the (admittedly over
simplified) (PHundamental ?) error handling framework.
And you could put in some realistic (and concrete)
error handling code snippets to indicate things that
might go wrong (as a danger signs for potential problems)
in future article example code using the error framework
that readers have gotten accustomed to -- rather than
vague comments which remind readers that
'Something can always go wrong'.
T. Gales & Associates
'Helping People Connect with Technology'
http://www.tgaconnect.com
More information about the talk
mailing list