You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Matías Mirabelli <ma...@globant.com> on 2009/10/07 20:47:39 UTC

OCM exceptions handling.

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.

Re: OCM exceptions handling.

Posted by Matías Mirabelli <ma...@globant.com>.
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 <ma...@globant.com>:
> > 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.
> >

Re: OCM exceptions handling.

Posted by Christophe Lombart <ch...@gmail.com>.
Hi Mathias,

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

Thanks
Christophe


2009/10/7 Matías Mirabelli <ma...@globant.com>:
> 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.
>