[
https://issues.apache.org/jira/browse/OAK-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270297#comment-13270297
]
Thomas Mueller commented on OAK-89:
-----------------------------------
I have the same concerns as Michael. I believe if we use checked exceptions in
too many places, we will end up with a lot of unnecessary and complicated
exception handling code. I'm afraid the alternatives listed by Jukka will not
always work:
> Changed the underlying API if the checked exception isn't really needed.
I don't think it would be easy to change a method that throws an OakException
to simply not throw it.
> Consider the exception (typically something like an IOException) a runtime
> issue... re-throw it wrapped into a generic RuntimeException.
I think we talk about OakException here, not IOException. To re-throw an
OakException as a RuntimeException (and back) could be avoided if OakException
is a RuntimeException.
> Pre-fetch the list of iterable values to memory
> Use some other API than Iterable/Iterator
Those doesn't work in most cases, because you don't know how large the list is
(whether it will fit in memory or not).
It's not only about iterators, it's also about comparing values, converting,
validation, caching, event listeners, and serialization/deserialization.
By the way, within the MicroKernel API, MicroKernelException is a
RuntimeException, and I don't think we got problems because of that.
I would make OakException which extends from RuntimeException for now, and
let's see if we get problems with that. If OakException is a checked exception,
with might as well use JCR exceptions instead.
> 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
>
> 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
