serving error pages in mvc: the control or the view?

Let's start by getting on the same page about MVC on the web. The control receives requests, selects a view, sends a response that it gets from the view. (Maybe the control gets data from the model, maybe the views do it themselves, I don't care.) Errors can occur, so we want to handle the errors and display a message or error page to the browser.

I'm trying to decide if these error messages/pages are part of the control or come from the view. Perhaps it is different for different kinds of errors.

some examples:

• The request path is meaningless, so we want to respond with a custom "not found" page.
  • The control selects the "not found" view and uses its response
  • The control builds the "not found" page itself

.

• The controller selects a view successfully, but the view throws an exception.
  • The view returns an error status. The controller checks the status and then selects a new view and uses its response
  • The view returns an error sta开发者_JAVA百科tus. The controller build the error response itself.
  • The view handles the exception and returns a valid error page or message to the controller. The controller blindly sends it as the response.

Now, the difference between the first two options in both cases is technical/organizational, and there is probably no difference to the user. Is there a standard opinion on this (perhaps across MVC frameworks) or is the choice just arbitrary? What is the preferred method?

The controller selects a view successfully, but the view throws an exception.

If the MVC design pattern is followed, this should never happen. The only logic that should be contained in a view is solely display logic (formatting, localizing etc).

Errors should be trapped either at the model or controller level, but it's up to the controller to decide what to do with the user (redirect/404/etc).

Edit:

Of course it's not the only way.. I'm sure that you can find hacked up, bastardized code all over the place that does different things. As far as I'm concerned, yes - your views should be engineered in such a way that errors will not need to be trapped (other than ajax/javascript errors, but that's where they belong anyway).

I usually set it up so that I have a different view for each HTTP error code I want to handle, and a generic one for a catch-all. The controller will be responsible in this case to pass the error data to the view for rendering (usually as an array). Of course, this could also be done using an ErrorModel (which would be the 'correct' way of implementing it - I'm just lazy ;))

The approach I take is to allow the controller to handle your first case (route based errors). Any request made that is either unauthorized or poorly formed gets managed by a "static content" controller that renders the appropriate error view.

For your second class of errors - I'm not sure how/if the view can communicate back to the controller that it's thrown an error. I'm actually interested to see other's opinions, because as far as I know if a view encounters an error, it's up to the view to deal with it.