Когда в WebAPI выбрано необработанное исключение, это нормально регистрируется ELMAH (в моей установке), и разумный ответ возвращается объекту jqXHR, который я могу прочитать.WebAPI StackOverflowException response
Но у меня была (теперь решена) проблема с разбором какого-то плохо структурированного JSON, который привел к исключению StackOverflowException в методе Deserialize (код ниже, только для контекста).
Моя проблема заключается в том, что это не рассматривалось как необработанное исключение, а вместо этого (IIS, я думаю) вернул ответ 500 с HTML-страницей «Внутренняя ошибка сервера» с сообщением «Услуга временно недоступна».
Это означало, что мой обработчик ошибок JavaScript разбился, поскольку он ожидал JSON, а не HTML в ответе.
Является ли StackOverflowException особым случаем, который по своей природе не может рассматриваться как необработанное исключение, как и любое другое, или существуют другие ситуации, когда ELMAH не регистрирует исключение, и это также приведет к тому, что сообщение HTML будет возвращается, когда ожидается JSON?
Или это означает, что в WebAPI вы должны поставить try/catch вокруг всего кода и предотвратить необработанные исключения, когда-либо возникающие?
private Models.Stream DeserializeStream(FileInfo dataFileInfo)
{
Models.Stream stream;
using (var streamReader = new StreamReader(dataFileInfo.FullName))
{
using (var reader = new JsonTextReader(streamReader))
{
stream = Serializer.Deserialize<Models.Stream>(reader);
}
}
return stream;
}
Только для избежания сомнений, что я не искал решение, почему исключение произошло (у меня есть что) только, как лучше обрабатывать эти типы исключений).
Спасибо. Полезно знать, что try/catch не поймает исключение StackOverflowException, созданное средой выполнения с .NET2.0. Спасло, что я трачу время, обворачивая свои услуги с ними. – Appetere