У меня точно такая же проблема. Вот как я это делаю:
bool shouldRetry = true;
do {
try
{
Stream newStream = myHttpWebRequest.GetRequestStream();
newStream.Write(byteArray, 0, byteArray.Length);
newStream.Close();
HttpWebResponse response = (HttpWebResponse)myHttpWebRequest.GetResponse();
shouldRetry = false;
response.Close();
tries++;
status = response.StatusDescription;
}
catch (WebException e)
{
tries++;
if (tries >= 5)
{
throw e;
}
else
{
Thread.Sleep(1000);
}
}
} while (shouldRetry);
Чтобы вызвать исключение, я изменил свою таблицу хостов, чтобы URI перешел к моему локальному хосту, который не дает правильного ответа.
Но исключение постоянно выбрасывается! Если я отлаживаю в Visual Studio, он останавливается на
throw e;
с уведомлением / коробкой "неучтенное исключение". если я нажимаю «play», чтобы продолжить отладку, то же исключение выдает строка, я не могу идти вперед в коде.
Кроме того, не имеет значения, ГДЕ я выдаю ошибку. Я попытался сохранить и выбросить его после do / while, после вызова функции и т. Д. Исключение все еще выбрасывается и постоянно присутствует. Единственный выход - остановить отладчик / выйти из веб-сервера. (на локальном хосте процесс занимает 100% своего ЦП), когда это состояние возникает на хосте веб-сервера, IIS через некоторое время перезапускается.
Аарон, ты когда-нибудь решал эту проблему? Мне нужно это исключение, и я не могу его "проглотить".
ОБНОВЛЕНИЕ: 2010-12-16
Этот код находится в функции с именем send (). Эта функция на самом деле вызывается в ThreadPool.QueueUserWorkItem следующим образом.
ThreadPool.QueueUserWorkItem((object state) =>
{
Thread.Sleep(1);
try
{
send();
}
catch (Exception e)
{
throw e;
}
});
В настоящее время я пытаюсь выяснить, связано ли это с безостановочными исключениями, которые в конечном итоге приводят к сбою сервера в моем случае. Как я уже сказал .. Неважно, ГДЕ я ловлю исключение.
ОБНОВЛЕНИЕ: 2010-12-16 (часть 2)
Я НЕ получаю нескончаемую ошибку, если я избегаю использования ThreadPool.QueueUserWorkItem.
Я продолжу исследовать .. Но, возможно, я мог бы обойтись без ThreadPool.QueueUserWorkItem.
ОБНОВЛЕНИЕ: 2010-12-16 (часть 3)
Thread.CurrentThread.Abort();
Вместо броска ошибка решает мою проблему