Class Design: Error Reporting or Returning False
Moderator: General Moderators
Class Design: Error Reporting or Returning False
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?
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
Depending on the errors, I tend to return data through an error object, or through the error system with trigger_error()
-
magicrobotmonkey
- Forum Regular
- Posts: 888
- Joined: Sun Mar 21, 2004 1:09 pm
- Location: Cambridge, MA
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:
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.
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')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.
Last edited by McGruff on Sun Aug 07, 2005 1:09 am, edited 1 time in total.
For errors, I usually give a class-property the value of the error-message and 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.
Code: Select all
function test(){
...
if (!categories::get($id)){
$this->error="No category could be fetched";
return false;
}
}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.