<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
+1 on specific exceptions. <br>
<br>
Not sure about Runtime vs. not runtime exceptions. <br>
<br>
+1 on Kris's comment about being able to attach the task or command
or additional info to the exception. <br>
<br>
-1 on exception "codes": a message and maybe additional information
is enough. <br>
<br>
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. <br>
<br>
Thanks!<br>
Marco<br>
<br>
11-05-12 08:38, Mauricio Salatino:
<blockquote
cite="mid:CANzbnyXFDJjMp9oDXRb9yOGOiS9zS8c3FXaZSUAdEK+Do6nhOw@mail.gmail.com"
type="cite">We don't need, but that was my initial question.
<div>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
<div>
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.</div>
<div>
<br>
</div>
<div>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. </div>
<div><br>
</div>
<div>
Cheers</div>
<div><br>
<br>
<div class="gmail_quote">On Fri, May 11, 2012 at 9:31 AM, Kris
Verlaenen <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:kris.verlaenen@gmail.com" target="_blank">kris.verlaenen@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Having a
specific exception definitely would be useful, as it would<br>
allow you to add context, like doing a getTask() or
getCommand() or<br>
whatever we believe is valid (as the user might not know
anymore what<br>
he asked). Note that we recently did something similar in
master for<br>
exceptions when executing a script, where we then add info
about what<br>
process instance etc.<br>
<br>
If TaskException extends RuntimeException, I suppose we
don't really<br>
have to declare it in the interfaces?<br>
<span class="HOEnZb"><font color="#888888"><br>
Kris<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
On Fri, May 11, 2012 at 2:05 PM, Mauricio Salatino
<<a moz-do-not-send="true"
href="mailto:salaboy@gmail.com">salaboy@gmail.com</a>>
wrote:<br>
><br>
><br>
> On Thu, May 10, 2012 at 4:20 PM, Mauricio
Salatino <<a moz-do-not-send="true"
href="mailto:salaboy@gmail.com">salaboy@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi guys,<br>
>> I was reviewing the Human Task Module and
more specifically the HornetQ<br>
>> implementation.<br>
>> I was writing some tests to check the
behavior after a logical failure in<br>
>> the server side and I reach a point where
some design questions appear:<br>
>><br>
>> The following line tries to start a task
which doesn't exist in the<br>
>> server:<br>
>><br>
>> client.start(3, "");<br>
>><br>
>> Where client is -> TaskService.<br>
>><br>
>> This leads to a Runtime Exception in the
client side with a clear<br>
>> message:<br>
>> "Command OperationRequest faild due to No
Task with ID 3 was found!.<br>
>> Please contact task server administrator."
<-- not sure about the<br>
>> administrator part<br>
>><br>
>> I understand that we are throwing a Runtime
Exception to be able to not<br>
>> declare the exception inside the TaskService
interface, but...<br>
>> For real implementations the user will be
forced to do the following:<br>
>><br>
>> try{<br>
>> client.start(3, "");<br>
>> }catch(Exception e){<br>
>> assertEquals("Command
OperationRequest faild due to No Task<br>
>> with ID 3 was found!. Please contact task
server administrator.",<br>
>> e.getMessage());<br>
>> // or notify the UI about the
error using that message.<br>
>> }<br>
>> No matter the method that the user calls in
the client UIs the try/catch<br>
>> block will need to be included in order to
not break the app.<br>
>> So my question is: we already have the
TaskException class which extends<br>
>> RuntimeException, there are not too many
implementations, but we surely can<br>
>> add<br>
>> the TaskPersistence exception, logical
exceptions, etc.<br>
>> In my perspective adding the exception to
both interfaces (TaskService and<br>
>> AsyncTaskService) will provide a more clear
approach to the users that in<br>
>> the end will<br>
>> need to add the try catch no matter why.<br>
>><br>
>> In my opinion, this is just the first step of
providing our clients a way<br>
>> to notify the errors to their UIs.<br>
>><br>
>> Looking forward for your comments and
feedback!<br>
>><br>
>> Cheers<br>
>><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
jBPM/Drools developer
Utrecht, the Netherlands</pre>
</body>
</html>