[jbpm-dev] human task exceptions

[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 at gmail.com>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 at gmail.com>
> wrote:
> >
> >
> > On Thu, May 10, 2012 at 4:20 PM, Mauricio Salatino <salaboy at 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
> >>
> >> --
> >>  - MyJourney @ http://salaboy.wordpress.com
> >>  - Co-Founder @ http://www.jugargentina.org
> >>  - Co-Founder @ http://www.jbug.com.ar
> >>
> >>  - Salatino "Salaboy" Mauricio -
> >>
> >
> >
> >
> > --
> >  - MyJourney @ http://salaboy.wordpress.com
> >  - Co-Founder @ http://www.jugargentina.org
> >  - Co-Founder @ http://www.jbug.com.ar
> >
> >  - Salatino "Salaboy" Mauricio -
> >
>



-- 
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar

 - Salatino "Salaboy" Mauricio -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20120511/8441d4bd/attachment.html