[jbpm-dev] human task exceptions

Fri May 11 12:44:37 EDT 2012

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 at gmail.com>

> 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 at redhat.com>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 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
>>> >>
>>>
>>
>>
>>
>> --
>> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20120511/8b73ce23/attachment.html 