0

I have a more general question about how to divide the code and responsibilities of the model, view and controller within the MVC pattern. For a better understanding I am going to use an example case.

My Question

The application is divided into the model, view and controller. How is an error handled during some operation at the model-level which should be displayed in the view ?

I thought of two possibilities:

a) The model saves an error string and notifies the controller and the view. The view then polls the error string from the model and saves it. Afterwards the controller tells the view to display the error.

b) The model returns the error to the controller which passes it to the view to be displayed.

What would you say would fit best to the MVC pattern ? Or what would be closer to the MVC pattern ?

Thank you very much in advance

J.D.
  • 3
  • 1
  • From my experience with certain frameworks, you catch the exception in the controller for an action the controller made - writing to the model. Then you can throw a view back appropriate for the error. – ChiefTwoPencils Dec 20 '14 at 09:38

1 Answers1

2

There are mostly two approaches:

For the start we should remember about Command Query Separation (CQS) principle.

So we expect errors on commands when changing model state.

Your Model can either throw some kind of BusinesModelException exception or have a return value of option type. None then means success (no errors) and Some contains information about error.

Having operation result allows more easily to aggregate errors during validation for example and explicitly through method's signature notify callers about returned errors. In C# for example if not documented properly it's not very obvious which exceptions can be thrown.
Exceptions are also not good for performance if you have a large batch of operations some of which return error.
When exception is not get thrown we usually imply that application does not have corrupted state and Operation result conveys this more naturally whereas exceptions require convention (whether it is recoverable or not).

On the other hand exceptions can travel across the layers to the point where they really need to be processed. This allows code to be cleaner: for example I do not need to catch biz logic exceptions at all but make an exception filter in MVC which correctly converts it to the appropriate htmls status code and error message. Also intermediate layers stay unaware of all the kitchen related to the errors.

Exceptions more easily fit into Aspect Oriented Programming as well.

These two approaches can be combined.

I prefer exceptions.

Pavel Voronin
  • 11,811
  • 6
  • 54
  • 113
  • Thank you for you answer. So within MVC the controller would catch the exceptions of the operations on the model and passes it to the view to be displayed ? – J.D. Dec 20 '14 at 10:41
  • My answer is yes. contoller is aware of the View (client representation) it is his responsibility to prepare data for the view. But this preparation can have a quite complex logic if we decide that at different levels of user authorization we want different error representation due to security requirements. – Pavel Voronin Dec 20 '14 at 10:46
  • This blog post and comments can be interesting for you, I suppose: http://blog.ploeh.dk/2014/12/23/exception-messages-are-for-programmers/ – Pavel Voronin Dec 23 '14 at 12:30
  • Thank you, looks very interesting! – J.D. Dec 29 '14 at 15:25