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.
