Menu
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?
270
Catch Block In Java We use a catch block to handle exceptions. This is the block with the “catch” keyword. The catch block follows the try block. Whenever an exception occurs in the try block, then the code in the catch block that corresponds to the exception is executed.
Associated catch blocks are used to handle any resulting exceptions. A finally block contains code that is run whether or not an exception is thrown in the try block, such as releasing resources that are allocated in the try block. A try block requires one or more associated catch blocks, or a finally block, or both.
The except block is executed when an exception occurs within the try block. The optional else block is executed only if there were no exceptions after try and before finally . The finally block contains instructions that are always executed at the end, regardless of whether exceptions occurred in the try block.
You should only ever catch specific exceptions that you can meaningfully handle. Otherwise let the exceptions bubble up to a single exception handler for your app. Then learn to write exception-free code.
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.
133
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
