Почему WPF глотает исключения привязки данных? - PullRequest
20 голосов
/ 16 января 2010

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

Кто-нибудь может объяснить преимущества работы с данными, работающей таким образом? Я предполагаю, что - это преимущества, но пока я их не вижу (отказ от ответственности: я только начинаю с привязкой данных).

Ссылки на ресурсы, которые объясняют теоретические (или практические) причины для принятия этого решения, также будут работать.

Ответы [ 4 ]

9 голосов
/ 16 января 2010

Не знаю точно, но подозреваю, что это потому, что исключить некуда.

Предположим, у вас есть что-то, чьи свойства вы хотите связать, но иногда это что-то нулевое. (Например, {Binding Name.Length}, где Name - это строковое свойство, которое может иметь значение null.) В этом случае вы рады, что этот параметр не используется, поскольку вы знаете, что элемент управления никогда не будет отображаться, когда Name равно null (из-за, скажем, триггера) или потому что вы знаете, что это будет переходное состояние, пока источник привязки загружает свои данные.

Теперь предположим, что WPF распространял исключение NullReferenceException при попытке вызвать Length в пустой строке Name. В процедурном коде вы поймали это исключение и проглотили его, потому что знали, что оно мягкое. Но вы не можете поместить обработчик исключений вокруг кода привязки WPF. Он вызывается откуда-то глубоко внутри WPF. Таким образом, исключение будет всплывать вплоть до Application.Run, что не очень полезно для его обнаружения.

Так что вместо того, чтобы заставлять вас централизовать обработчики обязательных исключений в Application.Run, я думаю, что ребята из WPF решили проглотить сами исключения. Только теория, хотя ...

5 голосов
/ 16 января 2010

Я бы сказал, что это связано с тем, что стоимость создания исключения является непомерно высокой. Текущая реализация работает даже в том случае, если есть некоторые недопустимые привязки и в текущей форме, которые могут действительно оказать очень существенное влияние на производительность. Возьмите этот пример, создайте DataGrid, который выполняет связывание, и загрузите в него 1000 записей. Измерьте производительность со всеми привязками правильно и снова с одной из них неправильно. Разница значительная. Добавьте поверх этого стоящие экземпляры класса исключений, и он может выйти из-под контроля. Просто мое мнение.

4 голосов
/ 16 января 2010

Я не знаю, почему это поведение по умолчанию, но есть способы обойти.

Например, даже если он не сообщит вам об ошибке привязки, появится окно «Вывод». Вы также можете отследить это, используя проверки привязки.

EDIT: Я нашел эту статью, в которой очень хорошая идея создать контрольные примеры, которые будут отлавливать эти досадные ошибки тихого связывания (и мне понравилась фотография в верхней части статьи)

0 голосов
/ 16 июня 2011

Вот ссылка на сообщение в блоге , в котором блоггер пишет о случае, когда он утверждает, что имеет смысл, что ошибки привязки молчат

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...