Вопрос

До сих пор я использую ServiceStack с отличными результатами, за исключением того, что дело с ошибками, казалось бы, сложно. Если что -то пойдет не так во время сериализации сообщения (потому что я забыл добавить конструктор по умолчанию в сообщение, например, все, что возвращает клиент, - это сообщение о том, что на сервере была внутренняя ошибка и код состояния 500. Добавление слушателя в а HttpApplication.Error Событие в Global.asax не работает, так как оно никогда не поражает. Тоже Application_Error. Анкет Мало того, что этого недостаточно для сценариев конечных пользователей, это делает отладка этих ошибок очень громоздкой, поскольку единственный способ выяснить, что пошло не так, это это уродливое выражение в быстрых часах:

Encoding.Default.GetString( ((System.IO.MemoryStream)((SyncMemoryStream)((System.Net.HttpWebResponse)(((WebException)ex).Response)).ResponseStream))._buffer)

Что я хотел бы, чтобы улавливать любые ошибки на стороне сервера (будь то сериализация с помощью ServiceStack или ошибок в моих услугах) и добавьте необходимую информацию в Errors Коллекция, которую есть все мои типы сообщений.

Это было полезно?

Решение

Смотрите ServiceStack's Проверка и обработка ошибок Страница вики для получения более подробной информации об обработке ошибок и проверке в ServiceStack.

На данный момент нет возможности справиться с исключением сериализации с помощью пользовательской логики (хотя теперь я добавлю это в список TODO :).

Если ваш ответ DTO имеет Ответестатус Собственность (т.е. или наследство от ihasresponsestatus), ServiceStack должен автоматически сериализовать ваше исключение.

Чтобы также заставить его сериализовать свой набор Stacktrace Режим отладки Чтобы true с setConfig () в вашем скрипте apphost.configure () Onload.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top