Well, I admit that the &quot;simples cases we need to catch exceptions&quot; argument is not a strong one, so probably you should forget it. But I mentioned it because it&#39;s something I&#39;ve been doing recently. It is not something important.<br>
<br>As I said on my first message, the backwards compatibility issue may have no practical effects, so probably no issues should come up.<br><br>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.<br>
<br>This is just my opinion and I can&#39;t make a stronger point than this. It won&#39;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&#39;s just how I think about the subject while writing my own APIs.<br>
<br><br><br><div class="gmail_quote">2012/5/11 Mauricio Salatino <span dir="ltr">&lt;<a href="mailto:salaboy@gmail.com" target="_blank">salaboy@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;m kinda against the argument of &quot;on simple cases we need to catch exceptions&quot;, 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.<div>


<br></div><div>If you still don&#39;t like the idea, I will go to the documentation option which is basically explain why we are not using checked exceptions :)  hehe</div><div><br></div><div>Cheers</div><div><div><div class="h5">
<br><div class="gmail_quote">

On Fri, May 11, 2012 at 2:43 PM, Kris Verlaenen <span dir="ltr">&lt;<a href="mailto:kverlaen@redhat.com" target="_blank">kverlaen@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On 05/11/2012 06:44 PM, Ramiro Pereira de Magalhães wrote:<br>
&gt; I&#39;m also favorable to specific exceptions, but I would like to see<br>
&gt; them under a meaninful class hierarchy. TaskException could be the<br>
&gt; parent class of many others. This would simplify a lot the exception<br>
&gt; handling.<br>
</div>I think this is already the case.<br>
<div><br>
&gt;<br>
&gt; Also, make them RuntimeExceptions. First, because you already put in<br>
&gt; the method a statement declaring what exceptions it may throw, so the<br>
&gt; exception handling &quot;protocol&quot; is already clear to client software<br>
&gt; developers. Second, you won&#39;t break backwards compatibility (not sure<br>
&gt; if that has any practical effects). Third, there are those times when<br>
&gt; you just want to write a quick sample code and don&#39;t want to deal<br>
&gt; (yet) with exceptions.<br>
</div>Yes, for those two reasons, backwards compatibility and not having to<br>
catch exceptions every time for simple cases, my vote would be to make<br>
them runtime exceptions as well.<br>
<span><font color="#888888"><br>
Kris<br>
</font></span><div><div>_______________________________________________<br>
jbpm-dev mailing list<br>
<a href="mailto:jbpm-dev@lists.jboss.org" target="_blank">jbpm-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><div class="im">-- <br> - MyJourney @ <a href="http://salaboy.wordpress.com" target="_blank">http://salaboy.wordpress.com</a><div> - Co-Founder @ <a href="http://www.jugargentina.org" target="_blank">http://www.jugargentina.org</a><br>


 - Co-Founder @ <a href="http://www.jbug.com.ar" target="_blank">http://www.jbug.com.ar</a><br> <br> - Salatino &quot;Salaboy&quot; Mauricio -</div><br>
</div></div>
<br>_______________________________________________<br>
jbpm-dev mailing list<br>
<a href="mailto:jbpm-dev@lists.jboss.org">jbpm-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a><br>
<br></blockquote></div><br>