Error handling in the model, or in the controller?

I asked around on vari开发者_StackOverflow中文版ous IRC channels but was unable to get an answer with a definitive explanation behind it. Should errors (pertaining to the model, such as transaction failures) be handled in the model, or in the controller?

Thanks in advance for any help.

EDIT

Well, the confusing thing is that my code (in the model) looks something like this already:

try
{
    // Connect to MongoDB
    // Fetch a record
}
catch (MongoConnectionException $e)
{
    // Handle this error
}
catch (MongoException $e)
{
    // Handle this error
}

So, should I return exceptions based on the exceptions MongoDB returns? Or should I directly allow these exceptions to bubble up to the controller?

Thanks!

---

The correct answer is "Both", but mostly in the Model.

The appropriate thing for your controller to do is simply catch some exception that the model throws, and handle outputting a nice "whups" message. Depending on how you're structuring your models, it might be appropriate for the controller to do some logging.

Anything other than catching the exception, maybe writing to a log (if your model infrastructure doesn't do it), and displaying a pretty error, does not belong in your controller.

---

Errors such as a transaction failure - and what to do in such cases - are business logic issues. Thus, they should be handled in the model and appropriate notifications passed back up to the controller.

Fat model, skinny controller.

---

In most cases, you should throw or pass exceptions to the caller/receiver AKA Controller or BLL.

It's controller's job to process actions not model
It's view's job to display a message box(or whatever) not model

You can't HANDLE exceptions in model, for real... you can only log or throw them.

---

Scott Guthrie for ASP.NET C# suggests using the Controller as the exception handler. He also, suggests setting up helper objects and handlers for the project. This in turn allows you to continue your development as normal.

Note, however with PHP MVC is still in its earliest stages and implementation so, this may not be perfect.

I do think that once you have decided how to handle the solution that you still with it and follow that pattern once you have made the decision.

---

The ideas behind MVC frameworks are quite simple and extremely flexible. The idea is that you have a single controller (such as index.php) that controls the launch of applications within the framework based on arguments in the request. This usually includes, at a minimum, an argument defining which model to invoke, an event, and the usual GET arguments. From there the controller validates the request (authentication, valid model, request sanitization, etc.) and runs the requested event.

At present the are only really two true frameworks...and this could be a problem for coding, support and future releases. Though, there are alot of frameworks that extend themselves to support MVC.

By Earliest stages, I mean to say and suggest that the current frameworks, solutions and support is limited as a result of rushed deliveries and poor documentation. Additionally, I'm suggesting what works for me and has worked for me in the past.

I would strongly This Website