views:

246

answers:

4

I'm using the MVC pattern in a .NET winform app. There are places in the Controller that can cause an exception. Rather than catching the exception and dislpaying a messagebox, which is a View responsibility, I do nothing in the Controller and let the View wrap that area in a try/catch. So far, there isn't anything that needs to be done in these exceptions except display a nice message to the user. That won't always be the case. The View than displays the exception error in a messagebox. I don't like this because the Exception classes come from the model. So, the View is reaching directly into the Model to gain access to the exceptions. But, how else can it be done and still follow the MVC pattern?

I could have the Controller handle the exception and throw a string back to the UI. How is that done though? If functionA returns void, I don't want to modify its return type just to appaise the View.

A: 

Typically what I do is have the Presenter (Controller) expose an OnError event that the View listens to. The view then uses the info from that event to present a UI, update a status bar or whatever.

ctacke
A: 

Ah! Makes sense. Controller communicates back to the View this way already.

4thSpace
A: 

I couldn't completely get away from this since I use Generic Events. I'm using the event model for Exceptions but the events are generic. That requires the caller to know about your generic event. Still, that all comes through via intellisense in the View and still makes the View very stupid :)

4thSpace
+1  A: 

I feel that its the Controllers responsiblity to tell the view to show a message and what message to show.

Therefor, I would put a DisplayError(string) method on the view and call that when you catch the exception in the Controller. That way the controller does the exception handling that the view still manages the details of displaying a message box with the message I tell it to use.

giltanis