webaddict is spot on about the bubbling up of exceptions, exceptions are also great because you can extend the exception object and make special case exceptions that each have their own abstracted behaviors, so common error handling functionality is pushed back into one common area thats easy to maintain / update.
Over-use of exceptions on the other hand can actually become a bottleneck for your application, so like arboint said its important to not use them for things that should be return values.. A search that produces no results should be handled by passing NULL or 0 or an empty array or something, because no data in the database is a perfectly common scenario, in my opinion exceptions are more for communicating error codes across application layers, for example if your'e codeing using a web service, exception handling should be written in. Basically I think they should be used when you can't restructure the code to handle a condition gracefully without using exceptions, a model using another model is a good example... but it would be more "correct" to catch and handle the exception within the model being called like..
Code: Select all
class modelA
{
function __construct() { throw new Exception('An exception occured');
}
class modelB
{
function __construct{
try
{
new modelA();
}
catch( exception $e )
{
//whatever
}
}
}
or would it be better for modelA to catch its own exceptions and just return false? That is the part thats still fuzzy to me... in this example im checking that the model instantiated correctly which is a bad example, but lets say I was just calling a method instead of instantiating the class, and I knew the method was callable I just didn't know if that method was going to produce an exception