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

[William Trenker]

Phillip J. Eby wrote:

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

Yes, you're right.  I wasn't suggesting one configuration file for an
entire, complex application.  Your decomposition, at the level of
distinct functional units, is realistic.  

I was thinking about "related configuration information" at an even
lower level.  For example, if a class loads configuration data I would
think the configuration data for that class should come from a single
file just as the method code for that class comes from a single file. 
If that class loads both structured and unstructured configuration data
then it makes sense for both ZConfig and .ini formats to be supported in
a single configuration file.

Mind you, I'm not suggesting each class have its own configuration file.
 That would be a system administration nightmare.  Since most distinct
functional components of an application consist of several or many
classes, it makes sense that the configuration data for those classes
be combined into one file representing the configuration needs of the
component.  But that still satisfies the condition that all the
configuration data for a given class is in a single file.  Hope that
makes sense.

Another vague, esoteric thought is how the co-location of mixed
configuration formats might help standardize the eventual creation of a
unit-testing sub-framework for PEAK.  What I'm thinking about is the
idea of unit-testing features that intrinsically support PEAK's tight
relationship between a unit's code modules and its configuration files. 
But right now these are just wispy thoughts floating high in the sky.

Bill