Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4177A550.4030807@lfjr.net>
Date: Thu, 21 Oct 2004 14:02:24 +0200
From: Emmanuel Bourg <smanux@lfjr.net>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [configuration] Concerns with ConfigurationRuntimeException
References: <41778FC9.8030702@btinternet.com>
In-Reply-To: <41778FC9.8030702@btinternet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ricardo,

Ricardo Gladwell wrote:
> Hi All,
> 
> I recently noticed the addition of the ConfigurationException 
> ConfigurationRuntimeException exception classes. The API now throws a 
> mixture of both of these. As I mentioned earlier, I'm still concerned 
> with throwing a RuntimeException in the API.

Currently ConfigurationException is only thrown when loading and saving 
a configuration.

Runtime exceptions are throw in:

- XMLConfiguration() when the XML APIs are missing 
(ConfigurationRuntimeException). This case is quite rare but I don't 
mind using a checked exception here, the other constructors throw a 
ConfigurationException.

- PropertiesConfiguration.unescapeJava(String) when a malformed unicode 
value is found (ConfigurationRuntimeException). This should not throw an 
exception, I would drop the character from the string and log a warning. 
However this happens only on loading the configuration, this may be 
assimilated to a parsing exception when loading an XMLConfiguration.

- JNDIConfiguration.getKeys() when a NamingException occurs 
(ConfigurationRuntimeException). Let's make it consistent with 
DatabaseConfiguration and just log the error.

- In Configuration/DataConfiguration getters when the property is 
incompatible with the requested type (ConversionException). This is 
documented.

- For unsupported write operations in read only configurations like 
JNDIConfiguration and the o.a.c.c.web configurations 
(UnsupportedOperationException). This is documented too. Should we just 
log an error ?

- For missing properties (NoSuchElementException) if 
throwExceptionOnMissing is set. It's unavoidable for the primitive 
getters if no default value is provided.

Let me know if I missed an exception.


> Currently, ConfigurationRuntimeException are used to signal that an 
> unrecoverable error has occured in the underlying data access layer 
> (i.e. it wraps an SQLException when an error occurs in the database 
> layer, or an FileException in the file i/o layer, etc). I would argue 
> that we should instead use the nestable ConfigurationException to nest 
> exceptions thrown when reading/writing to the underlying data access 
> API. All methods that potentially access data should declare that they 
> throw a ConfigurationException (which is nearly all the method 
> declartions in the Configuration interface).

I'm not fond of this. It only affects the configurations using an 
unreliable communication channel to access the properties, that's 
JNDIConfiguration and DatabaseConfiguration, the most widely used 
configurations are file based and not affected by this issue, why 
annoying their users ? Also this may prevent us from making 
Configurations implement the Map interface, I still want to try this.

> Runtime exceptions can be catastrophic especially for applications that 
> aren't expecting them (and, since they aren't declared in the class 
> interface or the javadoc, there is no reason for people to expect them). 
> They can cause whole applications to crash when they could otherwise 
> have handled or ignored the exception, or simply exited gracefully.

I agree

> I can understand why people would want to throw runtime exceptions 
> instead of regular exceptions during application initialisation when the 
> config API is normally used. After all, if you are missing important 
> configuration information you probably want to report this error, 
> However, there are also many cases where I can imagine you would want to 
> ignore configuration exceptions, for example, when reading configuration 
> information that is not mandatory to execute an application.

If a property is not mandatory a default value should always be 
specified, this eliminates the NoSuchElementException from the problem. 
Now what should we do when a ConversionException occurs ? If a default 
value is provided, we may want to return it instead of throwing the 
exception, this could be configured with a 
"throwExceptionOnIncompatibleProperty" flag, or using a special 
decorator (NoExceptionConfiguration ?)

> Someone else mentioned that one of the reasons that the configuration 
> interface does not declare any exceptions is that it would make code too 
> messy catching exceptions. However, I do not agree that this is a 
> sufficient reason to not declare thrown exceptions, for the following 
> reasons:
> 
> http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html

I don't want to declare a ConfigurationException on every method of the 
Configuration interface, logging data access errors is fine imho, but 
there are some unexpected and undocumented runtime exceptions that 
should be removed (the most important is in 
JNDIConfiguration.getKeys()). The case of ConversionException should 
also be examined.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org