Какова наилучшая практика обработки исключений в Silverlight?

В ASP.NET я обычно регистрирую исключения на стороне сервера. В формах Windows я могу либо регистрировать исключения на стороне сервера, либо записывать в файл журнала на клиенте. Кажется, что Silverlight находится где-то посередине.

Я хотел знать, что делают все остальные, чтобы справляться с исключениями Silverlight, и мне было любопытно, если для этого еще не созданы лучшие методы.

Ответы

Ответ 1

Для реального ведения журнала, который вы можете хранить и отслеживать, вам нужно будет сделать это на сервере, так как вы не можете гарантировать, что что-либо на клиенте будет сохранено.

Я бы предложил разоблачить метод "LogEvent (..)" на веб-службе на стороне сервера (возможно, у вас уже есть), который затем выполнил бы тот же вид ведения журнала, который вы делаете в ASP.net

Здесь видео об основных вызовах веб-службы в Silverlight, если вы еще этого не сделали http://silverlight.net/learn/learnvideo.aspx?video=66723

Я не уверен в каких-либо лучших методах ведения журналов, но первым соображением я хотел бы сделать наилучшие практики для входа в веб-службу на сервере и разоблачить это для клиента.

Надеюсь, это поможет!

Ответ 2

Я бы сказал, что Silverlight лучше подходит для ASP.NET-модели. У вас есть сервер, который обслуживает веб-страницу. Объект (приложение Silverlight) на странице запрашивает службу данных для извлечения данных и их отображения.

Весь доступ к данным происходит на стороне сервера, и не имеет значения, используются ли данные для создания страниц ASP.NET на сервере или отправки raw в RIA для отображения. Я регистрирую любые сбои в службе данных на стороне сервера (журнал событий работает отлично) и не допускает, чтобы какое-либо исключение проходило к WCF. Когда клиент не получает ожидаемые данные (он получает нулевую коллекцию или что-то подобное), он отображает общую ошибку доступа к данным для пользователя. Возможно, нам потребуется продлить это, чтобы передать немного больше информации (различая отказ в доступе/недостачу базы данных/отказ инфраструктуры/внутреннюю ошибку /etc ), но мы не планируем передавать клиенту сообщения об ошибках.

Что касается клиентской стороны, иногда мы можем попасть в ситуацию, когда время асинхронного вызова заканчивается - это просто другое сообщение. Для общих исключений из кода клиента (как правило, ошибок в нашем коде) я просто передаю исключение в браузер, чтобы отображать его так же, как и любое исключение script.

Ответ 4

Также ознакомьтесь с новым пакетом интеграции Silverlight для корпоративной библиотеки из Модели и методы Microsoft. Он обеспечивает поддержку регистрации исключений для изолированных хранилищ или удаленных служб и настраивается с помощью политик во внешней конфигурации или программно. Также поддерживаются протоколирование пакетов и автоматическая повторная попытка (в случае случайных сценариев).

Ответ 5

Это очень зависит от типа приложения, которое вы разрабатываете.

если его архитектура на основе mvc/mvp, то ваша модель, или большая ее часть, по крайней мере, будет на сервере, и именно здесь вы будете брошены большинство ваших исключений, поэтому я могу представить их там, выберите отображение сообщения пользователю или нет.

для исключений от клиента вы можете узнать подробности, чтобы просто отправить их обратно.