Perché WPF inceppare le eccezioni del databinding?

Question

Sono in procinto di apprendere WPF e sono perplesso dal fatto che le eccezioni del database non causano un'eccezione di runtime/non gestita.

Qualcuno può spiegare i vantaggi dell'elaborazione dati lavorando in questo modo? Suppongo che ci siano i vantaggi, ma fino ad ora non ne vedo alcuno (disclaimer: sto solo iniziando con l'associazione dati).

I collegamenti alle risorse che spiegano le ragioni teoriche (o pratiche) per prendere questa decisione funzionerebbero altrettanto bene.

Answer 1

I don lo so per certo, ma ho il sospetto che sia perché non c'è nessun luogo dove gestire l'eccezione.

Supponiamo di avere qualcosa a cui si desidera associare le proprietà, ma a volte qualcosa è nullo. (Ad esempio, {Binding Name.Length}, dove Nome è una proprietà stringa che potrebbe essere nullo.) In questo caso sei contento che questo sia un no-op, perché sai che il controllo non verrà mai mostrato quando il Nome è nullo (dovuto a un trigger dire) o perché sai che questa sarà una condizione transitoria mentre la fonte di binding sta caricando i suoi dati.

Supponiamo ora che WPF abbia propagato la NullReferenceException durante il tentativo di chiamare Length sulla stringa Nome null. Nel codice procedurale, prenderesti questa eccezione e la inghiottire perché sapevi che era benigno. Ma non è possibile inserire un gestore di eccezioni attorno al codice di binding WPF. Viene chiamato da qualche parte in profondità all'interno di WPF. Quindi l'eccezione dovrebbe arrivare fino a Application.Run, che non è un posto molto utile per catturarlo.

Quindi piuttosto che farvi centralizzare i gestori di eccezioni di binding fino in Application.Run, penso che i membri del WPF abbiano deciso di ingoiare le eccezioni da soli. Solo una teoria però ...

Answer 2

Non so perché questo è il comportamento predefinito, ma ci sono modi per aggirare.

Ad esempio, anche se non viene indicato l'errore di associazione, verrà visualizzata la finestra Output. Puoi farlo anche usando le convalide vincolanti.

EDIT: Ho trovato this articolo che ha una buona idea di creare casi di test che cattura quei fastidiosi errori di associazione silenziose (e mi è piaciuto la foto in cima all'articolo)

Answer 3

Direi che è perché il costo di produrre un'eccezione è proibitivo. L'implementazione corrente funziona anche nel caso in cui vi siano alcuni binding non validi e nella forma attuale che possono effettivamente avere un effetto molto significativo sulle prestazioni. Prendi questo esempio, crea un DataGrid che esegue il binding e questo carica 1.000 record in esso. Misurare le prestazioni con tutti gli attacchi corretti e di nuovo con uno di loro sbagliato. La differenza è notevole. Aggiungi sopra quelle istanze di classi di eccezioni in piedi e potrebbe andare fuori controllo male. Solo la mia opinione.

Answer 4

Ecco collegamento a un blog post in cui il blogger scrive di un caso in cui si sostiene che non ha senso che gli errori di rilegatura sono silenziosi