PHP5 exception - how do you handle them in MVC?

[Loomy]

I've been using a lot of MVC for my PHP5 projects recently, as well as using pretty much every OOP related functionality it can handle (private this, static that, etc, etc.). But I've never used exceptions other that just briefly testing them out to see how they work (no surprices, since I'm already well known with how they work in Java).

So, if I were to use them on, say, my next relatively large MVC project, in what layer should I handle the exceptions? As far as I can see there's a few possibilities:

• Catch them in database related classes (DAOs) and throw them to the Controller, then;
• catch them in the Controllers and handle printing of error messages, logging, etc, directly from there, or;
• throw them further to the View layer and handle error messages, etc, there.

Or maybe:

• Catch them in DAOs and handle the printing of error messages/logging/whatever immediately without any further throwing

What would you prefer/recommend?


EDIT: Maybe this should've been in the PHP Application Design section. Ah well..

[kyberfabrikken]

Exceptions are a generic mechanism for handling errors. As such, they don't belong in one layer. You should generally handle an exception as close to the throw-point as possible. Because exceptions bubble up through the call stack, you can have generic error handlers at the higher levels, and more specific handlers at the lower levels. You should at least have a final catch at the top-level (generally, somewhere in your controller layer), which logs an error, and displays some sort of http-500-page to the user.

[devbanana]

What I do in .NET and what seems a pretty good recommendation for PHP as well, is to catch the exception at the boundary of a layer, do something with the exception (like logging it somewhere), then wrapping it or replacing it with something more generic and sending it up the call stack unless it can be recovered from.

So if you have an exception in the data access layer, you catch it as high as possible in that layer, maybe since those exceptions are generally fairly serious you might want to log it to email or something. Then you replace it with say a more generic BusinessException or something of the sort, and send it on its way up to the next layer up until finally in the UI layer you can let the user know what happened, without giving any technical details because all that should've been logged already.