I was looking into GEOS-4754, and discovered that the documentation around “CatalogException” is rather unclear.
Justin - you seem to be the original author of this code, so if you have any insight it would be helpful.
My main question is: Is the Catalog responsible for reverting any changes it may have made when a CatalogException is thrown, or is this a responsibility of the client?
More details here: https://osgeo-org.atlassian.net/browse/GEOS-7865
Thanks
Hey Torben
Someone can correct me if I’m wrong and we never quite formalized this but here is my take/understanding. If the catalog throws an exception deliberately then it should be responsible for leaving/restoring modifications accordingly to the same state as before that method was called. If that doesn’t happen I would say it’s a bug.
The catalog isn’t however responsible for restoring any state “across methods”. For instance if adding a resource, then a layer and the layer method throws an exception. Removing the resource would be the responsibility of the client.
$0.02
-Justin
On Thu, Nov 17, 2016 at 12:29 PM Torben Barsballe <tbarsballe@anonymised.com> wrote:
I was looking into GEOS-4754, and discovered that the documentation around “CatalogException” is rather unclear.
Justin - you seem to be the original author of this code, so if you have any insight it would be helpful.
My main question is: Is the Catalog responsible for reverting any changes it may have made when a CatalogException is thrown, or is this a responsibility of the client?
More details here: https://osgeo-org.atlassian.net/browse/GEOS-7865
Thanks
Ok, that makes sense.
Right now, the Catalog does not revert anything if an exception is thrown.
I’ll look into improving this behavior.
Torben
On Thu, Nov 17, 2016 at 5:53 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hey Torben
Someone can correct me if I’m wrong and we never quite formalized this but here is my take/understanding. If the catalog throws an exception deliberately then it should be responsible for leaving/restoring modifications accordingly to the same state as before that method was called. If that doesn’t happen I would say it’s a bug.
The catalog isn’t however responsible for restoring any state “across methods”. For instance if adding a resource, then a layer and the layer method throws an exception. Removing the resource would be the responsibility of the client.
$0.02
-Justin
On Thu, Nov 17, 2016 at 12:29 PM Torben Barsballe <tbarsballe@anonymised.com> wrote:
I was looking into GEOS-4754, and discovered that the documentation around “CatalogException” is rather unclear.
Justin - you seem to be the original author of this code, so if you have any insight it would be helpful.
My main question is: Is the Catalog responsible for reverting any changes it may have made when a CatalogException is thrown, or is this a responsibility of the client?
More details here: https://osgeo-org.atlassian.net/browse/GEOS-7865
Thanks