There are basically two times when a system needs to be configured: before execution and during operation. As discussed in the previous section, much if not all of the configuration parameter information is processed during initialization. In addition to reading these data to obtain the required context information, the system must also handle gross errors and/or configuration inconsistencies. A proven approach is to ignore an inconsistency, choose a sensible default, and log the error. If you can't ignore the error, stop processing and inform the user .
One drawback of requiring that configuration data be processed during system initialization is that the user may have to shut down and restart for seemingly trivial changes. This may be acceptable for simple systems, but is likely to become intolerable for complex systems. For example, it is often best if log data (discussed in greater detail in Chapter 14), can be turned on and off while the system is running. Or consider configuration data in high-availability systems. Such systems need to be designed so that there is a way to notify the system of important changes to configuration data, or so the system can discover important changes during normal operation on its own. A key consideration is any data that may be useful for problem diagnosisit's always best to gather the data needed while the system is running, when the error occurs.
A special case of complexity in configuration parameters deals with pass-through parameters, that is, parameters set in the context of your application but are actually passed through to in-licensed components . Suppose, for example, that your system relies on a third-party text searching engine. The structure of its configuration parameters will constrain the structure of yours, including whether or not you can set its parameters during system operation. Because of this, the tarchitect must consider which configuration data are best handled during initialization and which are best handled while the system is operating.