Please see my previous email on client exception handling. I think you
should change onError to receive an InvocationException rather than a
throwable. You should be able to extract the HttpResponse from the
InvocationException. This is useful for the case where you want a
callback for a specific entity, an error happens, and you want to review
the response:
class InvocationException extends ClientException {
HttpResponse getResponse();
}
interface InvocationCallback<T> {
void onComplete(T thing);
void onError(InvocationException ie);
}
This works for both:
a) class MyCallback implements InvocationCallback<Customer> {...}
b) class MyCallback implements InvocationCallback<HttpResponse> {...}
In case (a) you can get to the HttpResponse within onError() through
InvocationException if you need to do complex error handling. In case
(b) InvocationException.getResponse() returns null as there was an
unforeseen internal error and there's no HttpResponse object.
You also might want to consider ditching the whole thing and forcing the
user to use an HttpResponse:
interface InvocationCallback<T> {
void onComplete(HttpResponse<T> response);
void onError(Throwable exception);
}
On 8/25/11 10:11 AM, Marek Potociar wrote:
> FYI: I reverted the extra events support, but kept the error and normal completion separated.
>
> Marek
>
> On 08/25/2011 04:01 PM, Santiago Pericas-Geertsen wrote:
>>
>> On Aug 25, 2011, at 9:43 AM, Bill Burke wrote:
>>
>>> I don't understand why you need all this complexity. If the user needs more control, then they should declare InvocationCallback to use an HttpResponse.
>>>
>>> As for error conditions, because onComplete() currently takes a Future as a parameter, you could throw the same exceptions from Future.get() as SyncInvoker throws.
>>>
>>>
>>> i.e.
>>>
>>> public class MyCallback implements InvocationCallback<Customer> {
>>>
>>> public void onComplete(Future<Customer> future) {
>>>
>>> try {
>>> Customer cust = future.get();
>>
>> Personally, I find this an abuse of the Future type. I can't get around the idea of an "onComplete" method that gets a "Future" as an argument. It's either complete or it isn't.
>>
>> I much prefer the onComplete/onError approach without any Futures, just like a CompletionHandler in JDK 7's NB I/O API.
>>
>> -- Santiago
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com