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