CODEWITHSUNDEEP
c#.netwpfbinding
Cartesius00
Cartesius00

Reputation: 24364

WPF Command and exception in ViewModel

button has a Command binding into ViewModel (it runs some Save method in ViewModel). Method Save can fail and throw an exception.

What is a best practice how to catch those exceptions? It would suffice to show a MessageBox but I do not want to do it in ViewModel (this is not the right way).

Upvotes: 9

Views: 5643

Answers (2)

blindmeis
blindmeis

Reputation: 22435

why you think its not the right way to show a messagebox? cause of unit test for the viewmodel? if thats your problem just write a IMessageBoxService which you use in your vm.

this post shows how to create a dialog service. so you have to improve it a little bit to get the messageboxservice you want.

Upvotes: 8

Damascus
Damascus

Reputation: 6641

1 - I don't believe it's "not the right way".

Having an Exception raised in ViewModel is typically part of the ViewModel logic. Therefore, showing a MessageBox there wouldn't be "the bad way". Keep in mind that the actual aim of MVVM is NOT to eliminate ALL code-behind, but is actually to clearly separate UI-logic and business-logic. An exception will happen when dealing with business objects -- you can handle it in the ViewModel

2 - Anyway if you want to stick with this approach (I'd qualify it as an extremist MVVM - heh -) you could:

  • Use a validator (have you heard about Binding.ValidationRules ? if not, this article should be useful for you ) to ensure data entered won't create an Exception
  • Define a specific return value if an Exception happens, ie. try-catch, and if you ever happen to enter in catch, you'll return a specific Error value which will be treated by UI as an error (you could for example use a Trigger to color the field in red if this specific error value has been returned)

Anyway again I think that there are a lot of people who want to apply an "extremist MVVM" by eliminating all possible code-behind and introducing complex patterns (Attached Behaviors for example...) just to follow a requirement which is actually nonsense in my opinion. I won't say I'm absolutely right, but I prefer to see MVVM as a pattern which will simplify my way of coding than a pattern which will introduce me so much pain for basic things (for example I've seen people implementing AttachedBehaviors for a simple DoubleClick action. I personally add an EventHandler firing the DoubleClick command to my MVVM when the DoubleClick event is fired. 1 line of code against a 100-lines class + XAML code for the other approach, choose your side. I believe that a simple problem should have a simple solution)

Cheers!

Upvotes: 8

Related Questions