Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
<?php
// included class page, created object
try {
$data = $prodObj->getRandomProducts();
if ($data !== FALSE) {
$productArray = $data;
}
else {
// no data in array, 0 records.
}
}
catch (Exception $e) {
var_dump($e->getTrace());
}
?>
On the index page I want to use $productArray to display products.
If you want to show an error page, that suggests changing the view and it should be done in the controller.
If you want to show the same page but with an error message, that suggests doing it in the view. However I think I'd use a second view for it instead of passing the information along to your index view.
From the 3 aspects that you described ( 1. Class page 2. 'Controller' page 3. index page) I can't understand what is the “top” . Generally , exceptions should be cached through the top level component of an application. By top I mean the one that is in the core of the app and generates all the others (e.g. the index.php isn't the top normally because it is just the instantiator of the front controller in MVC). That doesn't mean that each tier of the app should try – catch , the opposite. They should if they have to do something with that exception and then through it back to parent. If children's or other tiers only catch the exception to through it up (or again) there is no meaning to do so and is a sign of a week understanding of what Exceptions are (in my opinion).
It seems like $prodObj->getRandomProducts() should generate the exception and then whatever code above it can deal with the exception. Having that if() indicates that maybe you are calling things in the wrong place.
The question I would ask is: what is the exception communicating? Is it that some actual error occurred? Or is it just that no product records were found? For me the difference is what the View code displays to the user. If it is an error then I want to display something that the user can tell tech support that communicates the problem. If it is just no records then just display that no records were found.
It seem like the index page that uses the data should get the $prodObj object. It can then catch the exception if there is a database error, or separately check if no results are returned and let the user know about that.
I guess my question is: Why do you need an exception? It seems like if($data) is all you need. Either some random products are found, or the array is empty. If there is a syntax error it will show up in the logs. An SQL error should be fixed in development. So either display the random products or show that there are none.
currently it helps with debugging but should something happen during the query process i'd like the application to degrade as gracefully as possible - replace the error message with something more user friendly and email the error message to an administrator
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering