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?
