Передача объекта исключения к веб-сервису
Строго говоря нет никакого различия в значении; таким образом, выбор сводится к удобству.
Вот несколько факторов, которые могли влиять на Ваш выбор:
- стиль Дома: Некоторые группы разработчиков уже используют одно соглашение или другой.
- Клиентские требования: Вы будете использовать кавычки в строках? (См. ответ Ady).
- язык Серверной стороны: люди VB.Net могли бы принять решение использовать одинарные кавычки для JavaScript так, чтобы сценарии могли быть созданной серверной стороной (VB.Net использует двойные кавычки для строк, таким образом, строки JavaScript легки к выдающемуся, если они используют одинарные кавычки).
- код Библиотеки: Если Вы пользуетесь библиотекой, которая использует конкретный стиль, Вы могли бы рассмотреть использование того же стиля сами.
- Персональное предпочтение: Вы могли бы думать один, или другой стиль выглядит лучше.
5 ответов
При использовании WCF это было бы несложной задачей. Реализуйте собственный IErrorHandler для отправки ошибок в службу ведения журнала. Класс FaultException
Вы можете сериализовать объекты исключений. Фактически это необходимо для передачи объекта исключения от сервера к клиенту в случае возникновения исключения при вызове веб-службы. Вот почему System.Exception имеет перегрузку конструктора , которая создает объект исключения из сериализованных данных .
Пример кода для сериализации / десериализации объекта исключения:
private static void SerializeException(Exception ex, Stream stream)
{
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(stream, ex);
}
private static Exception DeserializeException(Stream stream)
{
BinaryFormatter formatter = new BinaryFormatter();
return (Exception)formatter.Deserialize(stream);
}
// demo code
using (Stream memoryStream = new MemoryStream())
{
try
{
throw new NullReferenceException();
}
catch (Exception ex)
{
// serialize exception object to stream
SerializeException(ex, memoryStream);
memoryStream.Position = 0;
}
// create exception object from stream, and print details to the console
Console.WriteLine(DeserializeException(memoryStream).ToString());
}
При этом, как говорится, Я, вероятно, согласился бы где-нибудь регистрировать тип исключения, сообщение и трассировку стека, чтобы я мог изучить информацию.
Что ж, есть несколько способов приблизиться к этому. Раньше я просто делал то, что я бы назвал сверхнаивной сериализацией XML, которая подключалась к чему-то вроде
<exception>
<type></type>
<Message></Message>
<StackTrace></StackTrace>
<innerException></innerException> //this would have the same schema as the root exception
</exception
и просто передавала это. Мне не нужно было десериализовать его для того, что я делал. Я просто регистрировал техническую часть и отображал сообщение пользователю, когда веб-сервис не удался.
Другой вариант - просто выполнить двоичную сериализацию в таблицу db, передать ключ в эту таблицу по сети и повторно обработать исключение из двоичного кода из базы данных.
В этом нет необходимости. Просто зарегистрируйте исключение.
Если вы хотите зарегистрировать его в базе данных, продолжайте. Для этого можно использовать блок приложения для ведения журнала корпоративной библиотеки.
Да, это возможно, в случае, когда ваше программное обеспечение находится на удаленном сайте, вы можете регистрировать его локально и периодически отправлять эхо-запросы на «материнский корабль» через ваш веб-сервис.
Это весьма неплохо. эффективный способ сбора информации о необработанных исключениях в «дикой природе» и их разрешения.
Если вы собираете трассировку стека, она обычно достаточно хороша, чтобы дать вам подсказку, в чем проблема. Однако в сборках выпуска вы не получите никаких номеров строк.