Почему WPF глотает исключения привязки данных?
Я нахожусь в процессе изучения WPF и озадачен тем, что связывающие с данными исключения не вызывают время выполнения/необработанное исключение.
Кто-либо может объяснить преимущества привязки данных работы таким образом? Я предполагаю, что существуют преимущества, но до сих пор я не вижу никого (правовая оговорка: Я просто начинаю с привязкой данных).
Ссылки на ресурсы, которые объясняют теоретическое (или практичный) причины того, чтобы принять это решение, работали бы также.
3 ответа
Я точно не знаю, но я подозреваю, что это потому, что некуда справиться с исключением.
Предположим, у вас есть что-то свойства, с которыми вы хотите связать, но иногда что-то ноль. (Например, {имя привязки.length} , где имя представляет собой свойство строки, которое может быть нулевым.) В этом случае вы будете рады, что это будет неоператор, потому что вы знаете контроль Никогда не будет показано, когда имя NULL (из-за спускового крючка) или потому, что вы знаете, это будет преходящее условие, когда источник связывания загружается его данные.
Теперь предположим, что WPF распространяется на NullReferenceException при попытке вызовов длины на строке NULL NAME. В процедурном коде вы хотите поймать это исключение и проглотить его, потому что вы знали, что это было доброкачественным. Но вы не можете поместить обработчик исключения вокруг кода связывания WPF. Это вызывается из-за глубокого внутреннего WPF. Таким образом, исключение будет пузыриться до Application.run, что не очень полезное место, чтобы поймать его.
Так что вместо того, чтобы сделать вас централизовать обработчики исключений, все в Application.run, я думаю, что ребята WPF решили проглотить самими исключениями. Только теория, хотя ...
Я не знаю, почему это поведение по умолчанию, но есть пути вокруг.
Например, даже если он не расскажет вам об ошибке связывания, выходное окно будет. Вы можете уловить, что также используют проверку привязки.
Редактировать: Я нашел Эта статья статья, которая имеет очень хорошую идею для создания тестовых случаев, которые будут ловить эти раздражающие ошибки привязки (и я любил фотографию в верхней части статьи)
Я бы утверждал, что это потому, что стоимость производства Исключения непомерно высока. Текущая реализация работает даже в случае наличия некоторых недействительных привязок и в текущей форме, что на самом деле может оказать очень существенное влияние на производительность. Возьмем этот пример, создадим DataGrid, которая выполняет привязку, и это загрузит в нее 1000 записей. Измеряйте производительность со всеми привязками правильно и снова с одной из них неправильно. Разница значительная. Добавьте к этому стоячие экземпляры класса исключений, и это может выйти из-под контроля плохо. Только мое мнение.