36

My view model class has a method (not sure if that is good practice or if view models are supposed to be strictly property and property changing mechanisms) that connects to a service. Of course I want to handle any possible WCF exceptions when connecting or disconnecting.

Let's use endpoint not found as an example considering that is an exception that I would want to bring to the user's attention. Consider the rough code example:

public void Connect()
{
    ServiceClient proxy = null;
    try
    {
        proxy = new ServiceClient();
        proxy.Subscribe();
        // ...
    }
    catch(EndpointNotFoundException)
    {
        // should I do something here?
    }
    // .. other WCF related exception catches and a finally
}

Is it considered good practice to maybe invoke System.Windows.MessageBox.Show() directly within the catch or should I maybe rethrow the exception so another layer of my WPF application catches it? If so, where is the ideal place to catch such an exception?

Jeff LaFay
  • 12,882
  • 13
  • 71
  • 101
  • What exactly is the user meant to do about this exception? You should tell the user anything he needs in order to correctly "handle" this exception. If there's nothing the user can do about it, then don't tell the user anything exception, maybe, "Sorry, but something's wrong". – John Saunders Nov 19 '10 at 19:49
  • 2
    @John, the user doesn't need to save the world. I just need to present to the user that the distant end is not available. That's why I mention a MessageBox. This question isn't regarding what I should tell the user, I want to know how to elegantly deal with exceptions in the pattern I'm using. – Jeff LaFay Nov 19 '10 at 19:59
  • I handle WCF faults in this manner: [MSDN](http://msdn.microsoft.com/en-us/library/dd470096%28VS.96%29.aspx) – Gabe Nov 19 '10 at 19:13
  • Do you have any other links that may be appropriate for the MVVM pattern or maybe WPF since I'm using them? I'm not sure if Silverlight (I've never written silverlight apps) is the right example for my scenario. I'm more interested in where to catch exceptions in the pattern. – Jeff LaFay Nov 19 '10 at 19:28
  • This might help...http://blogs.microsoft.co.il/blogs/zuker/archive/2009/03/23/wcf-advanced-error-handling-and-ierrorhandler.aspx – Gabe Nov 19 '10 at 19:49

1 Answers1

42

I've been handling exceptions in my MVVM client by catching them and wrapping them in an ErrorViewModel property of whatever ViewModel caught the exception.

Let's say a ViewModel A catches the EndpointNotFoundException. To present this error, I wrap the Exception in an ErrorViewModel and assign that to A's Error property.

The View associated with A contains a ContentControl bound to A's Error property. Meanwhile, I use a DataTemplate to associate an Error View to the ErrorViewModel. In that View, Visibility is determined by whether or not A's Error property contains an exception.

So A's View contains an error-message View that will only appear when an exception is caught, and can be dismissed by the user (an OK button on the error-message View invokes a command on A that clears A's Error property, thereby changing the error-message View's visibility to Collapsed).

Thus far, this seems to be a good approach that preserves proper MVVM decoupling.

Hope that helps. One way or another, honestly, I'd consider System.Windows.MessageBox.Show() in a WPF app as purely a last resort. Why give up rich control over the UI in favor of that old thing? Speaking of which, here's another popup-implementation approach.

Community
  • 1
  • 1
Dan J
  • 16,319
  • 7
  • 50
  • 82
  • I figured a MessageBox would be last resort (and secretly hoping so). – Jeff LaFay Nov 19 '10 at 19:43
  • 2
    I like this approach; it's the job of the ViewModel to represent a state that can be visualized. As such, an error that occurred somewhere in the Model should never be 'pushed' up to the View; rather, the state of the ViewModel should reflect that there has been an error. I could also see propagating the error up to some ErrorDisplayService, with a centralized mechanism for exposing error states from various sources. – Dan Bryant Nov 19 '10 at 19:47
  • I like this very much. If I understand you, you would abstract any exception that means "I can't reach the other end" into some error to be displayed to the user. That's perfect. If this had been an API, I would have suggested wrapping such exceptions in another that says, "Can't reach the other end". – John Saunders Nov 19 '10 at 20:03
  • This solution is beautiful. Thanks djacobson! – Jeff LaFay Nov 19 '10 at 20:28
  • @Dan Bryant I've seen a few people mention something like an ErrorDisplayService, or some other implementation of a Mediator pattern (error presenters subscribe to receive error notifications, while error -handlers- subscribe to handle errors) in this context. The project I'm working on is currently small enough I've been able to avoid going in-depth, but I like the idea. :) – Dan J Nov 19 '10 at 20:58
  • @John Saunders You've got me, that's what I'm talking about. You can control what (if any) technical details are available to the user, and / or you can log / handle them elsewhere while the `ViewModel` presents them. @jlafay You're welcome. :) – Dan J Nov 19 '10 at 21:00
  • Thanks, that's really useful. A nice way to deal with it. – Tom Morgan Jul 12 '12 at 16:06