[
https://issues.apache.org/jira/browse/OAK-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527880#comment-13527880
]
Michael Dürig commented on OAK-189:
-----------------------------------
bq. I don't see such a decision in that issue.
It might not be eminent from the issue itself but this was pretty much the
result of the surrounding discussion back then.
bq. A deeper solution to this problem could [...]
I agree that this could be solved through a more profound refactoring. However,
my point is that checked exceptions don't compose and this code is a prime
example of what this leads to. In the end effect this hurts code quality.
People usually won't go the extra mile and refactor the code. They will in most
cases just want to get their job done, catch the exception and move on.
FWIW, skimming through the sources in oak-core/main, I quickly found 91 places
where exception handling smells. Most places even had multiple issues
associated with them:
* In 70 cases exception handling is forced upon the the consumer of an API
because the implemented API doesn't allow throwing exceptions.
* In 18 cases the checked exception is wrapped into a runtime exception. This
might not be wrong per se but it is part of the fall out from forcing code to
handle an exception where a caller higher up in the call chain might be in a
better position to handle it.
* In 6 cases an overly broad range of exceptions is caught (Exception,
RuntimeException, not even counting RepositoryException).
* In 27 cases there is no adequate logging.
* In 8 cases exceptions are misused for flow control.
* In 30 cases the exception in just swallowed even though a higher up caller
might well be able to handle it.
* In 5 cases the exception indicates a programming error and should be an
assertion.
> Swallowed exceptions
> --------------------
>
> Key: OAK-189
> URL: https://issues.apache.org/jira/browse/OAK-189
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
> Reporter: Thomas Mueller
> Fix For: 0.6
>
>
> Exceptions should not be silently swallowed. This is currently done in
> SessionDelegate$SessionNameMapper, methods getOakPrefix(),
> getOakPrefixFromURI(), and getJcrPrefix(). Those methods catch
> RepositoryException, don't log by default (only when using debug level), and
> don't log the exception stack trace or throw an exception.
> Catching a very wide band of exceptions (RepositoryException) and then simply
> returning null is not an acceptable solution in my view.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
