|
From “CatalogListener.java”:
> * In general the catalog protects itself against misbehaved listeners that throw
> * exceptions. However sometimes it is the case in which a listener must report an error
> * via exception. For such purposes {@link CatalogException} should be thrown.
When the catalog actually recieves a CatalogException, it just re-throws it and does not do any work to revert any changes that have been made.
This can cause various problems. For example, for  GEOS-4754 Open , when we try and create a layer group it gets added to the catalog, then the persistor throws a CatalogException, meaning that the layer group is not persisted. However, the act of adding the layer group to the catalog is never reverted.
A couple things need to be done here:
a) Some documentation work to clarify the pupose / intended usage of CatalogException, particularily whether or not the catalog is responsible for reverting changes, or if this is a responsibility of whatever is using the catalog / catching the CatalogException.
b) If CatalogException is intended to be thrown upstream (which is appears it is), the Catalog interface should be modified to indicate that certain methods can throw CatalogException. This is a rather substantial API change
|