+1 on specific exceptions. Not sure about Runtime vs. not runtime exceptions. +1 on Kris's comment about being able to attach the task or command or additional info to the exception. -1 on exception "codes": a message and maybe additional information is enough. Also, it would be nice to keep the exception throwing logic "centralized" -- that is, that we're not adding catch/throw logic all over the place but have only a few places where that happens. This helps track down bugs later. Thanks! Marco 11-05-12 08:38, Mauricio Salatino: We don't need, but that was my initial question. We wrap the Runtime Exception of the server and we propagate TaskException, which should not longer extends Runtime Exception and we add the Exception to the interface, or we keep using RuntimeExceptions and strongly documents that the user will need to call all these methods in a try/catch block if they want to build real apps, which I believe that is not as good as the IDE forcing them to catch TaskExceptions. I will definitely check the Script solution and then we will need to decide if documenting that is enough or we move the exception to the TaskService and AsyncTaskService interface. Cheers On Fri, May 11, 2012 at 9:31 AM, Kris Verlaenen <kris.verlaenen(a)gmail.com&gt;wrote: > Having a specific exception definitely would be useful, as it would > allow you to add context, like doing a getTask() or getCommand() or > whatever we believe is valid (as the user might not know anymore what > he asked). Note that we recently did something similar in master for > exceptions when executing a script, where we then add info about what > process instance etc. > > If TaskException extends RuntimeException, I suppose we don't really > have to declare it in the interfaces? > > Kris > > On Fri, May 11, 2012 at 2:05 PM, Mauricio Salatino <salaboy(a)gmail.com&gt; > wrote: > > > > > > On Thu, May 10, 2012 at 4:20 PM, Mauricio Salatino <salaboy(a)gmail.com&gt; > > wrote: > >> > >> Hi guys, > >> I was reviewing the Human Task Module and more specifically the HornetQ > >> implementation. > >> I was writing some tests to check the behavior after a logical failure > in > >> the server side and I reach a point where some design questions appear: > >> > >> The following line tries to start a task which doesn't exist in the > >> server: > >> > >> client.start(3, ""); > >> > >> Where client is -> TaskService. > >> > >> This leads to a Runtime Exception in the client side with a clear > >> message: > >> "Command OperationRequest faild due to No Task with ID 3 was found!. > >> Please contact task server administrator." <-- not sure about the > >> administrator part > >> > >> I understand that we are throwing a Runtime Exception to be able to not > >> declare the exception inside the TaskService interface, but... > >> For real implementations the user will be forced to do the following: > >> > >> try{ > >> client.start(3, ""); > >> }catch(Exception e){ > >> assertEquals("Command OperationRequest faild due to No > Task > >> with ID 3 was found!. Please contact task server administrator.", > >> e.getMessage()); > >> // or notify the UI about the error using that message. > >> } > >> No matter the method that the user calls in the client UIs the > try/catch > >> block will need to be included in order to not break the app. > >> So my question is: we already have the TaskException class which > extends > >> RuntimeException, there are not too many implementations, but we > surely can > >> add > >> the TaskPersistence exception, logical exceptions, etc. > >> In my perspective adding the exception to both interfaces (TaskService > and > >> AsyncTaskService) will provide a more clear approach to the users that > in > >> the end will > >> need to add the try catch no matter why. > >> > >> In my opinion, this is just the first step of providing our clients a > way > >> to notify the errors to their UIs. > >> > >> Looking forward for your comments and feedback! > >> > >> Cheers > >> > -- jBPM/Drools developer Utrecht, the Netherlands

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. 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. Those are my 2 cents. 2012/5/11 Mauricio Salatino <salaboy(a)gmail.com&gt; > Yes, that's the decision that we need to make: > > "Runtime vs. not runtime exceptions. " > > This decision will affect the end user and we need to be sure that we are > all OK with that. > > The rest of the discussion about exceptions should be internal to the ht > module in this case and if we can centralize or align the way > that we handle exceptions in the process engine as well it will be great > (don't forget the rule engine). > > Cheers > > On Fri, May 11, 2012 at 9:48 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: > >> +1 on specific exceptions. >> >> Not sure about Runtime vs. not runtime exceptions. >> >> +1 on Kris's comment about being able to attach the task or command or >> additional info to the exception. >> >> -1 on exception "codes": a message and maybe additional information is >> enough. >> >> Also, it would be nice to keep the exception throwing logic >> "centralized" -- that is, that we're not adding catch/throw logic all over >> the place but have only a few places where that happens. This helps track >> down bugs later. >> >> Thanks! >> Marco >> >> 11-05-12 08:38, Mauricio Salatino: >> >> We don't need, but that was my initial question. >> We wrap the Runtime Exception of the server and we propagate >> TaskException, which should not longer extends Runtime Exception and we add >> the Exception to the interface, or we keep using RuntimeExceptions >> and strongly documents that the user will need to call all these methods >> in a try/catch block if they want to build real apps, which I believe that >> is not as good as the IDE forcing them to catch TaskExceptions. >> >> I will definitely check the Script solution and then we will need to >> decide if documenting that is enough or we move the exception to the >> TaskService and AsyncTaskService interface. >> >> Cheers >> >> >> On Fri, May 11, 2012 at 9:31 AM, Kris Verlaenen < >> kris.verlaenen(a)gmail.com&gt; wrote: >> >>> Having a specific exception definitely would be useful, as it would >>> allow you to add context, like doing a getTask() or getCommand() or >>> whatever we believe is valid (as the user might not know anymore what >>> he asked). Note that we recently did something similar in master for >>> exceptions when executing a script, where we then add info about what >>> process instance etc. >>> >>> If TaskException extends RuntimeException, I suppose we don't really >>> have to declare it in the interfaces? >>> >>> Kris >>> >>> On Fri, May 11, 2012 at 2:05 PM, Mauricio Salatino <salaboy(a)gmail.com&gt; >>> wrote: >>> > >>> > >>> > On Thu, May 10, 2012 at 4:20 PM, Mauricio Salatino <salaboy(a)gmail.com >>> > >>> > wrote: >>> >> >>> >> Hi guys, >>> >> I was reviewing the Human Task Module and more specifically the >>> HornetQ >>> >> implementation. >>> >> I was writing some tests to check the behavior after a logical >>> failure in >>> >> the server side and I reach a point where some design questions >>> appear: >>> >> >>> >> The following line tries to start a task which doesn't exist in the >>> >> server: >>> >> >>> >> client.start(3, ""); >>> >> >>> >> Where client is -> TaskService. >>> >> >>> >> This leads to a Runtime Exception in the client side with a clear >>> >> message: >>> >> "Command OperationRequest faild due to No Task with ID 3 was found!. >>> >> Please contact task server administrator." <-- not sure about the >>> >> administrator part >>> >> >>> >> I understand that we are throwing a Runtime Exception to be able to >>> not >>> >> declare the exception inside the TaskService interface, but... >>> >> For real implementations the user will be forced to do the following: >>> >> >>> >> try{ >>> >> client.start(3, ""); >>> >> }catch(Exception e){ >>> >> assertEquals("Command OperationRequest faild due to No >>> Task >>> >> with ID 3 was found!. Please contact task server administrator.", >>> >> e.getMessage()); >>> >> // or notify the UI about the error using that message. >>> >> } >>> >> No matter the method that the user calls in the client UIs the >>> try/catch >>> >> block will need to be included in order to not break the app. >>> >> So my question is: we already have the TaskException class which >>> extends >>> >> RuntimeException, there are not too many implementations, but we >>> surely can >>> >> add >>> >> the TaskPersistence exception, logical exceptions, etc. >>> >> In my perspective adding the exception to both interfaces >>> (TaskService and >>> >> AsyncTaskService) will provide a more clear approach to the users >>> that in >>> >> the end will >>> >> need to add the try catch no matter why. >>> >> >>> >> In my opinion, this is just the first step of providing our clients >>> a way >>> >> to notify the errors to their UIs. >>> >> >>> >> Looking forward for your comments and feedback! >>> >> >>> >> Cheers >>> >> >>> >> >> >> >> -- >> jBPM/Drools developer >> Utrecht, the Netherlands >> >> > > > -- > - 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 > >

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