OCM exceptions handling.

3 messages Options
Embed this post
Permalink
Matías Mirabelli

OCM exceptions handling.

Reply Threaded More More options
Print post
Permalink
Hello guys, I hope all you're well.

We're working with JackRabbit OCM and we need to trap specific
exceptions depending on the context in which occurs, and the OCM just
throws three kind of exceptions: ObjectContentManagerException,
RepositoryException and JcrSystemException.

We need to catch exceptions such as PathNotFoundException or
CouldNotRemoveException, since commonly we use several operations inside
the same try block, for example:

try {
    jcrTemplate.remove("/my/repo/path");
    jcrTemplate.save();
} catch (ObjectContentManagerException ex) {
    // Here's the question.
}

Is there a way to know what exception was thrown without parsing the
message?. For the moment, we made a patch to the
ObjectContentManagerImpl in order to add some useful runtime exceptions,
avoiding ambiguous exceptions. If there's a better way for do it, I'd
appreciate your suggests, and I can send you the patch if the team
considers that may be useful.

I'll wait for your comments.

Thanks beforehand,

Matias.
Christophe Lombart

Re: OCM exceptions handling.

Reply Threaded More More options
Print post
Permalink
Hi Mathias,

Yes the patch can be useful.You can create a jira issue.

Thanks
Christophe


2009/10/7 Matías Mirabelli <[hidden email]>:

> Hello guys, I hope all you're well.
>
> We're working with JackRabbit OCM and we need to trap specific
> exceptions depending on the context in which occurs, and the OCM just
> throws three kind of exceptions: ObjectContentManagerException,
> RepositoryException and JcrSystemException.
>
> We need to catch exceptions such as PathNotFoundException or
> CouldNotRemoveException, since commonly we use several operations inside
> the same try block, for example:
>
> try {
>    jcrTemplate.remove("/my/repo/path");
>    jcrTemplate.save();
> } catch (ObjectContentManagerException ex) {
>    // Here's the question.
> }
>
> Is there a way to know what exception was thrown without parsing the
> message?. For the moment, we made a patch to the
> ObjectContentManagerImpl in order to add some useful runtime exceptions,
> avoiding ambiguous exceptions. If there's a better way for do it, I'd
> appreciate your suggests, and I can send you the patch if the team
> considers that may be useful.
>
> I'll wait for your comments.
>
> Thanks beforehand,
>
> Matias.
>
Matías Mirabelli

Re: OCM exceptions handling.

Reply Threaded More More options
Print post
Permalink
Christophe,

The patch is reported as a jira issue. You could look at the issue at
the following url:

https://issues.apache.org/jira/browse/OCM-38

Regards beforehand,

Matías.


On Fri, 2009-10-09 at 07:51 +0200, Christophe Lombart wrote:

> Hi Mathias,
>
> Yes the patch can be useful.You can create a jira issue.
>
> Thanks
> Christophe
>
>
> 2009/10/7 Matías Mirabelli <[hidden email]>:
> > Hello guys, I hope all you're well.
> >
> > We're working with JackRabbit OCM and we need to trap specific
> > exceptions depending on the context in which occurs, and the OCM just
> > throws three kind of exceptions: ObjectContentManagerException,
> > RepositoryException and JcrSystemException.
> >
> > We need to catch exceptions such as PathNotFoundException or
> > CouldNotRemoveException, since commonly we use several operations inside
> > the same try block, for example:
> >
> > try {
> >    jcrTemplate.remove("/my/repo/path");
> >    jcrTemplate.save();
> > } catch (ObjectContentManagerException ex) {
> >    // Here's the question.
> > }
> >
> > Is there a way to know what exception was thrown without parsing the
> > message?. For the moment, we made a patch to the
> > ObjectContentManagerImpl in order to add some useful runtime exceptions,
> > avoiding ambiguous exceptions. If there's a better way for do it, I'd
> > appreciate your suggests, and I can send you the patch if the team
> > considers that may be useful.
> >
> > I'll wait for your comments.
> >
> > Thanks beforehand,
> >
> > Matias.
> >