Re: [jbpm-dev] human task exceptions
Well, I admit that the "simples cases we need to catch exceptions" argument
is not a strong one, so probably you should forget it. But I mentioned it
because it's something I've been doing recently. It is not something
important.
As I said on my first message, the backwards compatibility issue may have
no practical effects, so probably no issues should come up.
Still, I think that a clear exception throwing protocol (i.e. a combination
of semantic exceptions, good messages, good exception context data and
clear statement about what exceptions a method throws and some
recomendations on how it should be handled) is enough for you to implement
a reliable client of a certain SPI. In my opinion, unchecked exceptions are
the simplest solution for the stated problem and, as a principle, an API
should not be more complex than necessary. AFAIK no one has presented an
issue with the client not having checked exceptions, so they are not
necessary. So, having no need for a more complex resources, I believe we
should favor the RuntimeException option.
This is just my opinion and I can't make a stronger point than this. It
won't bother me mutch to have TaskException a checked one because you can
always wrap one exception into another and work with your favorite kind.
That's just how I think about the subject while writing my own APIs.
2012/5/11 Mauricio Salatino <salaboy(a)gmail.com>
I'm kinda against the argument of "on simple cases we need
to catch
exceptions", as I mention we will only need to add a throws in your test
method. The backward compatibility argument is OK, I understand that, but
we have introduced those interfaces in the previous release and I think
that adding the exception there will make the difference. Braking
compatibility with real life clients will not make much difference, because
all those clients should be catching those exceptions now.
If you still don't like the idea, I will go to the documentation option
which is basically explain why we are not using checked exceptions :) hehe
Cheers
On Fri, May 11, 2012 at 2:43 PM, Kris Verlaenen <kverlaen(a)redhat.com>wrote:
> On 05/11/2012 06:44 PM, Ramiro Pereira de Magalhães wrote:
> > I'm also favorable to specific exceptions, but I would like to see
> > them under a meaninful class hierarchy. TaskException could be the
> > parent class of many others. This would simplify a lot the exception
> > handling.
> I think this is already the case.
>
> >
> > Also, make them RuntimeExceptions. First, because you already put in
> > the method a statement declaring what exceptions it may throw, so the
> > exception handling "protocol" is already clear to client software
> > developers. Second, you won't break backwards compatibility (not sure
> > if that has any practical effects). Third, there are those times when
> > you just want to write a quick sample code and don't want to deal
> > (yet) with exceptions.
> Yes, for those two reasons, backwards compatibility and not having to
> catch exceptions every time for simple cases, my vote would be to make
> them runtime exceptions as well.
>
> Kris
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev
Attachments:
- attachment.html (text/html — 4.9 KB)