[dev] Re: [core] error reporting/logging

Jan Schneider janmailing@gmx.de
Mon, 17 Sep 2001 17:25:47 +0200


Zitat von Chuck Hagenbuch <chuck@horde.org>:

> [moving to dev]
> 
> Quoting Jon Parise <jon@horde.org>:
> 
> > > I think it is worth holding up 2.4.0 to do a _thorough_ revamp
> > > of how we handle errors, and to at least make sure that they
> > > are logged somewhere with as much information as possible.
> > > Troubleshooting a lot of things is unnecessarily hard for
> > > people at this point.
> > 
> > I agree.  Where would you like to start?
> 
> There are two areas in which we need to improve. One is how errors are 
> displayed on the front end. That one I'm not as worried about; we can do that
> 
> incrementally. What I think we need to do before release is to make sure that
> 
> whenever there is an error, we log it to a global Horde log source. Not
> errors 
> like being unable to create a folder - we already give the user the necessary
> 
> information in that case, and I don't see a need to duplicate the IMAP server
> 
> logs there (though I could be swayed). But when we fail to run a query, can't
> 
> send mail, can't connect to a database, ldap server, etc. - then we need to
> log 
> the error details so that admins have a place to get better information.
> 
> So, I propose:
> 
> 1. a global Horde log source. Just a configuration section. I'll do it in a
> few.
> 2. a static method, Horde::logError(), which would hide the Log:: handle from
> 
>    the global namespace, make sure it was instantiated, etc. Also easy, but
> 
>    I'll wait for feedback.
> 3. Then we need to audit the code and add lots of calls to said method, 
>    including error details, messages, anything we can.
> 
> Thoughts?

I agree in all points. A static method would make it much easier using the 
logging mechanism and will probably lead to a more extensive use. 

Counterproduktive would be to overload the method with arguments. I propose to 
read the horde application from registry and just use the two arguments from 
the pear log(). We could alternatively give an error object or a string as the 
error message.

Jan.