i'm building an application using a pattern similar to the MVC. The situation is the next: in the context of the model making changes to the associated repository. If the change throw an exception what is the correct way to present the information about the error to the user? In the previous version of my program when i have spaguetti code organization (model, view, controller overlaped), launching a messagebox telling the user about the error wasn't weird because i was doing almost everything from the views. Now in this new version i want to do the things correctly, so i guess that is bad doing anything that has a visual representation in the model layer. Some time ago i ask what is the correct way to capture exceptions. The specific point i was refering was to scale up exceptions from an inner code to an upper layer vs capture them in the most upper layer. Almost all the response were that isnt a good approach scale exceptions(capture and throwing again to be captured by a responsable entity), and is better to capture in the most upper layer. So i have this conflict in my head. I was thinking that is inevitable to maintain the separation of concerns to scale up, but that is in conflict with those previous advices. How can i proceed?
A common pattern is to have a generic place to put errors in your existing model.
One easy way to do this is to have your model classes all inherit from a base model class that has a property of type IEnumerable<ErrorBase>, or some other type of your choosing.
Then, in your presenter, you can check the error collection and display as necessary.
As far as having exceptions bubble up, the approach I use (almost regardless of what type of application I'm building) is to only handle exceptions at lower levels if you are going to do some special logging (like logging important local variables), or if you can do something intelligent with that exception. Otherwise, let it bubble.
At the layer right before your presenter (or web service class, or whatever), that's when you can capture your exceptions, do general logging, and wrap them (or replace them with) a "sanitized" exception. In the case of the UI, you just make sure you don't reveal sensitive data and perhaps display a friendly message if possible. For web services, you turn these into some kind of fault. Etc.
The upper most layers aren't "responsible" for the bubbled exceptions, they're simply responsible for making sure those don't show up to the end users (or web service client, or whatever) it a form you don't want them to... in other words, you're "presenting" them appropriately.
Remember, separation of concerns is a paradigm that you should follow as a rule of thumb, not an edict that owns all. Just like leaky abstractions, there are leaky paradigms. Do what makes sense and don't worry about it too much. :)