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, 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).
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 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.
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
Kind regards,
-- Ricardo Gladwell
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
