Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Date: Wed, 9 May 2012 10:05:50 +0000 (UTC)
From: =?utf-8?Q?Michael_D=C3=BCrig_=28JIRA=29?= <jira@apache.org>
To: oak-dev@jackrabbit.apache.org
Message-ID: 
 <1804023301.43471.1336557950311.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <648242261.35709.1336415808522.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (OAK-89) Improve exception handling
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/OAK-89?page=3Dcom.atlassian.jir=
a.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13271266=
#comment-13271266 ]=20

Michael D=C3=BCrig commented on OAK-89:
----------------------------------

bq. The trouble with this approach is that the NameMapper can't know what k=
ind of a RepositoryException...

Right. That's why I said earlier (08/May/12 10:06) that when using checked =
exceptions, we should make them specific, not inherit from a common base ex=
ception, and keep them locally scoped. Otherwise we end with the same situa=
tion you just described plus all the noise which goes with checked exceptio=
ns.=20

bq. ... if it makes the code cleaner and/or safer, and doesn't lead to too =
much control flow

It makes it safer but noisier. And well, checked exceptions are a control f=
low construct. Only that no one dares to admit ;-)
               =20
> 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=C3=BCrig
>         Attachments: OAK-89-2.patch, OAK-89.patch
>
>
> As discusses on the @oak-dev list [1] we need to improve the way exceptio=
ns are thrown and handled.=20
> I suggest to create a OakException which extends from RuntimeException an=
d encapsulate a RepositoryException into it. These exceptions can then be h=
andled where appropriate. We can the later turn this into a more sophistica=
ted mechanism where the OakException is mapped to a corresponding Repositor=
yException 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 administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira