2012/5/11 Mauricio Salatino <salaboy@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@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@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@gmail.com> wrote:
>
>
> On Thu, May 10, 2012 at 4:20 PM, Mauricio Salatino <salaboy@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev