[jbpm-dev] human task exceptions

Fri May 11 12:54:47 EDT 2012

Ramiro, we don't have the exceptions in the method signature in the
interfaces that we are exposing. I'm not sure if as a developer want that
kind of context switch. If you want to create a test you can simply throw
the exception in the method test and don't use the try/catch blocks, which
for a real application you can't do.

And yes.. TaskException is the parent exception only.

Cheers

On Fri, May 11, 2012 at 1:44 PM, Ramiro Pereira de Magalhães <
ramiro.p.magalhaes at gmail.com> 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.
>
> 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
>>
>>
>

-- 
 - 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/83652846/attachment-0001.html 