jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Moseley <...@osafoundation.org>
Subject exception handling in jcr-server io subsystem
Date Thu, 08 Dec 2005 00:00:00 GMT
i'm in the middle of updating cosmo to use the current revision of 
jackrabbit, and one thing is giving me a bit of trouble - the fact that 
jcr-server's import/export subsystem only allows IOExceptions to be 
propagated up to the DavResource level. in fact, in some places it 
actively swallows RepositoryExceptions.

DefaultHandler.importProperties has several sections of code like this:

         try {
             // if context-encoding is null -> remove the property
             contentNode.setProperty(JcrConstants.JCR_ENCODING, 
context.getEncoding());
         } catch (RepositoryException e) {
             // ignore: property may not be present on the node
         }

and in one case:

         } catch (RepositoryException e) {
             // ignore: property may not be present on the node.
             // deliberately not rethrowing as IOException.
         }

in certain other places, RepositoryExceptions are rethrown as 
IOExceptions, losing the stack trace of the original exception in the 
process.

i understand that DefaultHandler is written to assume that a certain 
node type structure is validated by the canImport/canExport methods. 
however, RepositoryException can be thrown due to operational problems 
with underlying subsystems (ex: the PersistenceManager can't store a 
node or property because the operating system won't let it). the 
swallowing and/or lossy wrapping of RepositoryExceptions makes it much 
harder for us to track down when operational problems occur.

in the best of all possible worlds, RepositoryException would be 
unchecked and i would be able to insert code to handle it at whatever 
layer i want without affecting the method signatures of intervening layers.

however, given that this is not the case, i'd like to revisit the io 
subsystem and perhaps explicitly throw RepositoryExceptions where they 
make sense.

angela, what do you think?

Mime
View raw message