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!