Connection errors not forwarded to Delegate

[pbihler]

Currently the URL connection errors are lost in the LRRestyClientProxyDelegate, so they can't be handled by the application.

To hand them down, a chunk of code is missing in the LRRestyClientProxyDelegate implementation:

- (void)restyRequest:(LRRestyRequest *)request didFailWithError:(NSError *)error {
    if ([responseDelegate respondsToSelector:@selector(restClient:request:didFailWithError:)]) {
        [responseDelegate restClient:restyClient request:request didFailWithError:error];
    }
}

and the LRRestyClientResponseDelegate must be extended by:

@optional
/**
 * Called if the underlying URLConnection reported an error
 * @param client    The client performing the request.
 * @param request   The request resulting in an error.
 * @param didFailWithError  The error the URLConnection reported.
 */
- (void)restClient:(LRRestyClient *)client request:(LRRestyRequest *)request didFailWithError:(NSError *)error;

Any chance to see the bugfix in the nightly build soon?

Pascal

[lukeredpath]

Hi Pascal,

I'll look into this over the weekend.

Cheers
Luke

[pbihler]

Hi Luke!

That's good news. Do you think it is possible to put the 3-line fix I included into the nightly build the next days?

Currently, I workaround the fundamental bug (since I cannot handle e.g. server downtimes without the fix) with a category file for LRRestyClientProxyDelegate and a sub-protocol of LRRestyClientResponseDelegate, but that's really not very nice to present…

Thanks a lot,
Pascal

Am 23.09.2011 um 16:41 schrieb Luke Redpath:

Hi Pascal,

I'll look into this over the weekend.

Cheers
Luke

Reply to this email directly or view it on GitHub:
#17 (comment)

[lukeredpath]

Hi Pascal, yes, I'm sure I'll have time to look at this tomorrow.

Please do send me a link to your slides once you've presented them as I'd love to see them, even if they are in German.

[pbihler]

Hi!

Please do send me a link to your slides once you've presented them as I'd love to see them, even if they are in German.

I'll do, even if I don't know whether there will be many slides, since
it's a lot of "hands-on", thus live coding...

But there will be a video online, eventually.

Greetings,
Pascal

Dr. Pascal Bihler

University of Bonn, Institute of Computer Science III
Roemerstrasse 164, D-53117 Bonn, Germany

[pbihler]

Hi Luke!

Hi Pascal, yes, I'm sure I'll have time to look at this tomorrow.

Had you time to review the bugfix?

Sincerely,
Pascal

Dr. Pascal Bihler

University of Bonn, Institute of Computer Science III
Roemerstrasse 164, D-53117 Bonn, Germany

[lukeredpath]

Hi Pascal

I've taken a look but I can't quite see what the bug is. The code in your original message is already present. Am I missing something?

Luke

[pbihler]

Hi!

As far as I know, only the LRRestyRequestDelegate receives the
"restyRequest:didFailWithError:" message, thus (depending on which
method you called on the LRRestyClient instance) the
LRRestyClientBlockDelegate (who cannot do anything with it) or the
LRRestyClientProxyDelegate (who also doesn't do anything with it). So
the message it lost in the middle of your framework

As a Resty-Framework user, I only write a block or provide a
LRRestyClientResponseDelegate, neither of both receive a
didFailWithError: message.

So I proposed to extend the LRRestyClientResponseDelegate with an
optional method to catch the error, and to forward the error in the
LRRestyClientProxyDelegate to the LRRestyClientResponseDelegate.

++ Pascal

Am 26.09.11 15:29, schrieb Luke Redpath:

Hi Pascal

I've taken a look but I can't quite see what the bug is. The code in your original message is already present. Am I missing something?

Luke

Dr. Pascal Bihler

University of Bonn, Institute of Computer Science III
Roemerstrasse 164, D-53117 Bonn, Germany