Return-Path:
Some implementations of the Configuration
interface operate
on underlying storages that can throw exceptions on each property access.
@@ -319,88 +319,73 @@ config.clearProperty("removedProperty");
SQLException
.
- In earlier versions of Commons Configuration such exceptions
- were simply logged and then swallowed. So for clients it was impossible
- to find out if something went wrong. From version 1.4 on there is a new
- way of dealing with those internal errors: the concept of error
- listeners.
+ Because the Configuration
interface does not define checked
+ exceptions for the methods which access properties such exceptions
+ thrown from the underlying property store have to be handled somehow.
+ One way would be to re-throw them as runtime exceptions. This is
+ possible, a description how to enable this feature can be found in the
+ Tips and
+ Tricks chapter. An alternative way of dealing with such exceptions is
+ to register an event listener for error events.
- A configuration error listener is very similar to a regular configuration
- event listener. Instead of the ConfigurationListener
- interface it has to implement the
-
- ConfigurationErrorListener
interface, which defines a single method
- configurationError()
. In case of an internal error this
- method is invoked, and a
+ When a configuration implementation encounters an exception on accessing
+ its data it generates an event of class
- ConfigurationErrorEvent
with information about that error is
- passed. By inheriting from ConfigurationEvent
- ConfigurationErrorEvent
supports all information that is
- available for normal configuration listeners, too (e.g. the event type or
- the property that was accessed when the problem occurred; note that the
- isBefore()
method does not really make sense for error
- events because an error can only occur after something was done, so it
- returns always false is this context). This data can
- be used to find out when and where the error happened. In addition there
- is the getCause()
method that returns the Throwable
- object, which generated this event (i.e. the causing exception).
-
- We can now continue our example from the previous section and make our
- example configuration listener also capable of tracing error events. To
- achieve this we let the ConfigurationLogListener
class also
- implement the ConfigurationErrorListener
interface:
+ ConfigurationErrorEvent. This event class has similar properties
+ as
+ ConfigurationEvent
. Especially the name and the value of the
+ property which was accessed when the error occurred can be retrieved.
+ In addition, there is the getCause()
method which returns the
+ exception causing this event.
+
+ ConfigurationErrorEvent
defines some new event type constants.
+ They build up the following hierarchy:
+
errorOperationType
+ returns an EventType
object corresponding to the failed
+ update method (e.g. ConfigurationEvent.ADD_PROPERTY if a
+ property could not be added).
- Now the listener object has to be registered as an error listener, too.
- For this purpose AbstractConfiguration
provides the
- addErrorListener()
method. The following example fragment
- shows the registration of the log listener object:
+ We could now continue the example from the previous section and make our
+ sample logging event listener also capable of tracing error events.
+ However, this would not earn us that much. There is no principle difference
+ in the handling of configuration update events and error events;
+ therefore, there is nothing new to learn. If the logging functionality
+ should be implemented in a single listener class, the only tricky part is
+ that ConfigurationEvent
and ConfigurationErrorEvent
+ do not stand in a super/extends relation with each other; they are both
+ derived from the type Event.ANY. So a generic logging listener
+ would have to be of type EventListener<Event>
, and it
+ would have to use the event's type to determine how to handle this
+ concrete event. Creating a separate event listener class for logging error
+ events is certainly easier.
Note: AbstractConfiguration
already implements a mechanism
- for writing internal errors to a logger object: It has the protected
- addErrorLogListener()
method that can be called by derived
+ for writing internal errors to a logger object: It has the
+ addErrorLogListener()
method that can be called from derived
classes to register a listener that will output all occurring internal
errors using the default logger. Configuration implementations like
DatabaseConfiguration
that are affected by potential internal
errors call this method during their initialization. So the default
- behavior of Commons Configuration for these classes is not
- changed: they still catch occurring exceptions and log them. However by
- registering specific error listeners it is now possible for clients to
+ behavior of Commons Configuration for these classes is to
+ catch occurring exceptions and log them. However, by
+ registering specific error listeners it is possible for clients to
implement their own handling of such errors.