jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Moseley <...@osafoundation.org>
Subject Re: exception handling in jcr-server io subsystem
Date Thu, 08 Dec 2005 15:55:43 GMT
Angela Schreiber wrote:

> if you find other places e.g. during the import of data without
> an explaining comment its probably a bug.

you seem to be talking about swallowing RepositoryExceptions 
here. i understand why you did it in importProperties, tho i 
don't agree that swallowing every possible 
RepositoryException is correct.

> yes, 'a certain'... with the handlers available no check is made
> against the nodetype-definition that would reveal whether a
> certain property can be set or not :).
 >
> but of cause you may write your own handlers that assert
> the complete nodetype structure...

that's not my point. i'm not worried about structural 
exceptions, but rather operational ones. when i run out of 
disk and derby can no longer store properties, i want 
DefaultHandler.importProperties to throw that exception up 
the stack, not swallow it.

yes, i can write my own handler, but then i don't get to 
leverage the hundreds of lines of code in DefaultHandler and 
friends that are perfectly useful.

> i didn't throw RepositoryException on purpose, due to the fact,
> that the io-stuff was originally (thus already with the command-chains)
> designed to provide some abstraction of the import/export.
> currently i don't see a benefit of throwing RepositoryException(s).

you're taking the abstraction to such an extreme that we're 
losing important exception information.

IOException does not have a constructor that accepts a root 
cause exception, so even if i write a bunch of try/catch 
clauses to catch RepositoryExceptions and rethrow them as 
IOExceptions, i lose the stack trace of the original 
exception, and i have more useless lines of code to boot.

i think you've set the wrong goal by limiting exceptions in 
this way. it's not like you're somehow abstracting jcr out 
of the import/export process - ImportContext and 
ExportContext carry a node around. the only thing you're 
achieving here is throwing away information in a lower layer 
that is useful at a higher layer.



Mime
View raw message