[PEAK] Error handling (was Re: Unifying configuration)

William Trenker wtrenker at shaw.ca
Sun Dec 21 07:42:29 EST 2003


Phillip J. Eby wrote:

> Maybe certain kinds of components (such as commands) need to use an 
> "application error handling" service of some kind, so that startup errors 
> like ZConfig errors can not only be trapped, logged, and reported, but 
> application-specific messages can be obtained.

As a bare-minimum, does it make sense to have something like a high-level ConfigurationError exception?  The idea is that if any error is detected during parsing and instantiation of configuration data, then that exception would be raised.  As with any Python exception, the default action would be that the application would be halted, thus implementing a "failsafe" policy by default.  If a "proceed anyway" policy is required, then the programmer can catch the exception, let the user know something is wrong, and let the application continue.  This isn't particularly elaborate, but it would be a start.

A cursory reading of the PEAK config sources shows that even .ini parsing / processing can encounter various errors (Syntax, PropertyNotFound, etc.).  With ZConfig integrated inside .ini, what I am suggesting is that all ZConfig and .ini errors would be caught by a high-level Config "entity" (module, class or whatever), which would, in turn, raise the all-encompassing "CongigurationError".

Does this fit or is it off-the-wall?  I'm a real PEAK newbie so if this suggestion is too simplistic or architecturally out of place, I can take the chuckle.  I just like the idea of all related configuration info being in a single file.  Scattering related config info among more than one file is asking for trouble, in my opinion.

Regards,
Bill
 




More information about the PEAK mailing list