Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <1311634073.1215617131707.JavaMail.jira@brutus>
Date: Wed, 9 Jul 2008 08:25:31 -0700 (PDT)
From: "Thomas Mueller (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1674) Provide means for exception handling
 for QueryNodeVisitor implementations
In-Reply-To: <1408832418.1215610412850.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JCR-1674?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D126121=
46#action_12612146 ]=20

Thomas Mueller commented on JCR-1674:
-------------------------------------

+1 for this patch. I think using checked exceptions is a good solution.

I would use unchecked exceptions only if Jackrabbit as a whole also uses un=
checked exceptions. It would be inconsistent to use unchecked exceptions in=
 some places and checked exceptions in others. Communicating the error stat=
e using the data object doesn't sound like a good solution: you would have =
to check the error state everywhere.

> Provide means for exception handling for QueryNodeVisitor implementations
> -------------------------------------------------------------------------
>
>                 Key: JCR-1674
>                 URL: https://issues.apache.org/jira/browse/JCR-1674
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-spi-commons
>            Reporter: Michael D=C3=BCrig
>            Priority: Minor
>         Attachments: QueryNodeVisitor.patch
>
>
> Currently the methods of QueryNodeVisitor do not declare any exceptions. =
Even though the query tree might be syntactically correct, an implementatio=
n might reach a point where it cannot continue (i.e. if it does not support=
 one of the optional query features). For such cases there are currently tw=
o solution: 1. throw an unchecked exception or 2. communicate the error sta=
te through the visitor using the data object passed along.=20
> While I don't like 2. it is still an option. For 1. I'm not sure if this =
is the right way to go. It might be better to actually throw a checked exce=
ption. I therefore created a patch which declares RepositoryException on al=
l visit methods of QueryNodeVisitor. Although the necessary changes in clas=
ses using QueryNodeVisitor are trivial, there are quite many of them.=20
> Any opinions on checked exception with probably breaking (trivially) exis=
ting code vs. using not checked exceptions?

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.