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

[Phillip J. Eby]

At 12:42 PM 12/21/03 +0000, William Trenker wrote:
>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.

Two things: first, if you get an error parsing an executable ZConfig file, 
your application hasn't actually been loaded and started yet, so it can't 
continue.  This is the issue that Alexander was referring to.  Second, 
ZConfig doesn't support resuming parsing of a file containing an error anyway.


>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".

It would suffice to subclass the errors from a standard base for that 
purpose.  But it's still not going to help with either of the problems I 
mentioned above.


>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.

Many sophisticated setups for PEAK will involve multiple configuration 
files.  Take a look at the 'bulletins' example, which has two configuration 
files, not counting 'peak.ini' or the optional sitewide PEAK_CONFIG.  (If 
one were to develop an Eclipse-like IDE using PEAK, one would likely have 
an .ini or ZConfig file for each "plugin".)

These things are of course "related" in some sense, but naturally they are 
going to represent configuration for distinct components, or different 
aspects of the same component.  I'm not sure how this relates to your 
comments about multiple files.

Anyway, I'm not planning to add error-handling services during the 0.5a3 
development cycle, although it's *possible* I might add a traceback 
formatting service.  There were a few times today I really could have used 
a simplified traceback for errors in PEAK.

In future versions, though, there probably will be some type of error 
handling/reporting service.  It should be usable to create more 
user-friendly messages for configuration errors, but it's not going to 
permit a broken application to continue running.  You will, however, be 
able to section an application into components loaded from different files, 
in which case the application itself may be able to run, albeit without 
access to components whose configuration files are broken.  And, if a user 
has a broken PEAK_CONFIG, the application won't start at all unless an 
application is specifically written to work around that problem.