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@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@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 -