Question

我发布请求并检查错误，如下所示：

// Send request out on a background thread
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
    [postRequest performRequestWithHandler:^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error) {
        if ([urlResponse statusCode] == 200) {
            NSLog(@"Tweet Successful");
        }else {
            NSLog(@"Tweet Failed");
            if (responseData) {
                //  Use the NSJSONSerialization class to parse the returned JSON
                NSError *jsonError;
                NSArray *requestResponse =
                [NSJSONSerialization JSONObjectWithData:responseData
                                                options:NSJSONReadingMutableLeaves
                                                  error:&jsonError];

                if (requestResponse) {
                    NSLog(@"%@",requestResponse);
                } else {
                    NSLog(@"%@",jsonError);
                }
            }
        }
    }];
});

就请求而言，似乎工作正常。我的目的是将请求排除在失败状态，并在以后再次尝试，或者不依赖于错误以及到目前为止失败了多少尝试。我遇到的问题是，我发现它经常出现故障，错误34“找不到页面”，其中请求确实成功，按预期发布，可以在twitter流中看得清楚。

现在，如果我无法信任返回的错误代码，那么我无法继续并继续重试。我如何确定它是成功还是失败？

最近的观察：

最近，我试图直接从Apple照片应用程序发布照片，它向我发送了一条警告，上面写着“推文可能没有成功”。这很有趣，因为这基本上是我在这种情况下作为我唯一的选择。这让我觉得，即使是苹果也不得不承认，当回报没有确认时，没有办法确定帖子失败了。

Answer 1

根据研究此问题时发现的每个示例，其中没有一个使用任何其他API而不是您正在使用的API，并且包括this example from twitter's own documentation用于将照片发布到API，它们都不会首先检查urlResponse代码。

似乎要做的最多的是this example from twitter's documentation，其中执行GET然后处理响应。注意它首先检查responseData，如果它存在，它只是被视为成功。只有没有responseData才会试图查看错误。这个例子并不打扰urlResponse ...而且我在10分钟的谷歌搜索中看到的任何其他例子都没有。

（最后，我怀疑这很重要，或者可能是因为你清理了显示的示例，但是当你没有执行任何UI时，你正在处理主队列上的错误。你可以立即执行处理程序中的处理，并将您执行的任何后处理传递给您尝试显示它的任何UI。我怀疑在主队列中对响应进行后处理而不是处理程序的队列（如在这里引用的两个例子和我见过的所有其他例子中都显示了这个问题，但是我想知道它是否会减少你所看到的假阴性的发生率。至少，它会让你的回答和响应清理器的任何UI显示，效率更高。）

如何判断TWRequest performRequestWithHandler是否失败或成功

1 个答案: