Page 1 of 1

Class Design: Error Reporting or Returning False

Posted: Sat Mar 19, 2005 2:12 am
by nigma
Would any of the more experienced object orienters be willing to comment on when, if at all, you should die() from within a class to report an error instead of returning false?

Posted: Sat Mar 19, 2005 3:03 am
by Maugrim_The_Reaper
Generally I don't, returning false or other lets the base file decide what to do about an error. I think it all depends on how you want to handle errors...

Posted: Sat Mar 19, 2005 8:53 am
by feyd
Depending on the errors, I tend to return data through an error object, or through the error system with trigger_error()

Posted: Sat Mar 19, 2005 10:21 am
by magicrobotmonkey
yes, die()ing inside an object is generally a very bad idea. I will usually just return false and populate an $err variable.

Posted: Sat Mar 19, 2005 4:59 pm
by McGruff
Hopefully the programmer will have put a great deal of thought into identifying discrete roles and responsibilities for different objects. Good OOP designs have classes which do only one thing.

There are usually three main layers in a design: presentation, domain, and data access. Presentation is just the the UI, ie all input and output. In MVC (Model View Controller) the presentation layer is further split into View and Controller.

The Controller receives the request and decides what to do with it. It may manipulate the domain (or model) and selects a View.

The View collects the data it needs from the model and then outputs a page.

The domain (or model) contains all the business logic. It basically adds meaning to the raw data in persistent storage. For example domain objects might know how to calculate interest due on an account, or how to work out which forum topics have received a new post since the user's last visit.

The data access layer are objects which interact with persistent storage - usually (but not always) a database.

Note that this is a high-level view: there is no single class corresponding to each layer. Within each layer you'll find groups of co-operating classes. each doing just one thing. At least I hope you will.

With one short, simple die() command you would be driving a coach and horses through this careful layering. In effect you are selecting a view (ie a page) and making a call to tell a View action to execute. This is the job of the Controller in MVC.

You often see die() recommended in sql queries:

Code: Select all

mysql_query() or die('cannot access the database')
However, queries are carried out in data access objects, in the data access layer. These objects are responsible for one thing only - fetching data from persistent storage - and should not be given presentation responsibilities ie selecting and executing views.

Instead, you could pass a boolean return value back up through the layers to the Controller which can decide what to do next - eg display an error page.

Posted: Sat Mar 19, 2005 5:23 pm
by andre_c
why not throw an exception? (if you're using php5)

Posted: Thu Mar 24, 2005 11:37 am
by patrikG
For errors, I usually give a class-property the value of the error-message and return false

Code: Select all

function test(){
...
 if (!categories::get($id)){
  $this->error="No category could be fetched";
  return false;
 }
}
That way, whatever calls method test() knows it failed and can decide on whether its going to display the error message or not.

In the example above, the class obviously would need to be initialised.

To avoid this, you could, of course, write a an error-registry (see registry-pattern), which would probably be the cleanest solution.

Posted: Fri Mar 25, 2005 1:45 am
by nigma
Thanks a bunch for the advice. Definitely apreciated.