[
https://issues.apache.org/jira/browse/OAK-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271223#comment-13271223
]
Michael Dürig commented on OAK-89:
----------------------------------
bq. Here's how I'd define the error-handling for the NameMapper interface:
Ok, this works. I'm not sure however whether it is currently used everywhere
according to this contract.
Basically what you propose is to
# use runtime exceptions for indicating programming errors, and
# {{null}} to indicate "missing value" or "cannot compute".
For 1. I'm fine with that but would give slight precedence to using assertions
instead. Wrt. 2. while this seems to be standard Java practice, I don't see how
this is supposed to be better than throwing a specialised runtime exception
like I initially proposed. It is also not type safe and relies on the caller
explicitly checking for {{null}} (and forgetting to do so will incidentally
also end up in a runtime exception...). Throwing a specialised runtime
exception would give us the same type safety guarantees (namely none) but would
make the code less noisy because only the ultimate consumer in a chain of calls
would have to catch that exceptions and do something about it instead of every
method in the call chain having to cope with possible {{null}} values. So in a
way returning {{null}} is the worst of all worlds: (a) no type safety and (b)
putting the burden upon every caller up the chain. With runtime exceptions
there is only (a) and with checked exceptions there is only (b).
> Improve exception handling
> --------------------------
>
> Key: OAK-89
> URL: https://issues.apache.org/jira/browse/OAK-89
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
> Affects Versions: 0.2.1
> Reporter: Michael Dürig
> Attachments: OAK-89-2.patch, OAK-89.patch
>
>
> As discusses on the @oak-dev list [1] we need to improve the way exceptions
> are thrown and handled.
> I suggest to create a OakException which extends from RuntimeException and
> encapsulate a RepositoryException into it. These exceptions can then be
> handled where appropriate. We can the later turn this into a more
> sophisticated mechanism where the OakException is mapped to a corresponding
> RepositoryException by an injected mapping (see Jukka's proposal in the
> discussion).
> [1] http://markmail.org/message/t5czrpkvyamn7sym
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
