У меня есть следующая функция, которая доставит мне html-источник какого-либо веб-сайта через прокси-сервер, он работает нормально, за исключением некоторых случаев, когда сервер возвращает 503 (сервер недоступен) или любое другое исключение, которое никогда не входит в оператор catch.
в операторе catch предполагается, что функция вызывает себя рекурсивно, до 4 раз, если запрос продолжает сбой после 4 попыток, возвращается значение null.
private static string GetPageHTML(string link,bool useprx)
{
int tryCount = 0;
WebClient client = new WebClient() { Proxy = new WebProxy(ProxyManager.GetProxy()) { Credentials = new NetworkCredential("xx", "xx") } };
try
{
return client.DownloadString(link);
}
catch (WebException ex)
{
var statuscode = ((HttpWebResponse)ex.Response).StatusCode;
{
if (tryCount == 3)
{
return null;
}
switch (statuscode)
{
case (HttpStatusCode.Forbidden):
tryCount++;
System.Threading.Thread.Sleep(5000);
return GetPageHTML(link, useprx);
case (HttpStatusCode.NotFound):
return null;
case (HttpStatusCode.GatewayTimeout):
tryCount++;
System.Threading.Thread.Sleep(5000);
return GetPageHTML(link, useprx);
case (HttpStatusCode.ServiceUnavailable) :
tryCount++;
System.Threading.Thread.Sleep(5000);
return GetPageHTML(link, useprx);
default: return null;
}
}
}
}
так почему это никогда не входит в оператор catch?
tryCount
является местным. Когда вы рекурсивно вызываете метод, он получает другой локальный адрес. Если ваш рекурсивный вызов метода завершится ошибкой, он вызовет сам себя, снова с новым локальным адресом. Я думаю, вы обнаружите, что наблюдать за значением tryCount, равным 3, должно быть трудно. Возможно, вы захотите провести рефакторинг и либо передать количество в качестве параметра, чтобы отслеживать его, либо, что предпочтительнее, провести рефакторинг потенциального сбойный код дальше, чтобы вы могли изолировать его и отслеживать его за пределами этой точки сбоя. - person Anthony Pegram   schedule 28.03.2013