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.
On 05/11/2012 06:44 PM, Ramiro Pereira de Magalhães wrote:I think this is already the case.
> 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.
Yes, for those two reasons, backwards compatibility and not having to
>
> 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.
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