views:

80

answers:

4

Hi!

I asked around on various 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!

+2  A: 

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.

Kalium
Sorry to sort of go off topic, but in that case how would you suggest passing the notifications back up to the controller? Global constants? Especially in cases where there are multiple errors that could occur, I fear that constants would become necessary. Then again, do you think that they are acceptable for use in these situations, or have an entirely different method?
Jonathan Chan
Models should clean up whatever mess they've made (ensure the system is in a valid state), and throw some type of exception, which your controller-layer can catch and handle.
timdev
A: 

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.

Joe Garrett
Jonathan Chan
Out of curiosity, if *PHP MVC is still in its earliest stages and implementation* what is it missing? I mean, it's not like the pattern is that complex, right?
Gordon
object development model in PHP is infantile and still isn't yet up to what I would consider fully fledged OOP. Though, this is an opinion...and as such should be taken with a grain of salt. There are many work arounds and solutions that would allow you to operate a full MVC application.
Joe Garrett
+3  A: 

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.

timdev
Hi! I've stated the problem I face with that approach in the updated question - could you please explain your position on how I should take care of that?Thanks!
Jonathan Chan
Take a connection exception as the example. Can your model take any meaningful action? Probably not, mongo went away. If your models have a logging infrastructure baked in, you might want write something to your log. But since this is not fixable, you're going to have to eventually throw a new exception for your controller to catch. If there's nothing at all for your model to do, don't even catch the exception there, just let it bubble up to the controller.
timdev
Thank you very much for that explanation, timdev! You put it very clearly and explain the logic behind your decision. Thank you! :)
Jonathan Chan
A: 

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

Joe Garrett
Thank you for the link, Joe. I checked it out and the idea would seem to apply to PHP MVC too. Thanks!
Jonathan Chan