ad************* @gmail.com schrieb:
I've just finished reading the article below which goes into some
depth about exceptions. The article was rather lucid and so I
understand how to implement it all, the thing I'm having trouble with
though is why would I need to them?
The usefulness of exceptions is highly discussed and it's easy to start
flame wars over this topic. First of all, there are more ways to handle
errors than you stated: The "simple error handling techniques" are split
up into several more:
- return some magic error code integer or false if it didn't work
- use trigger_error() to raise an error
- return an error object (PEAR does this)
- (insert your approach here)
error codes
------------
These are widely used! It's the C language way of handling errors. The
problem with the error code approach is that you are responsible to
remember that a function might return an error EVERY TIME YOU USE IT.
Example: You use a function and forget the error handling. Some time
later an error happens and is not handled. Because you did not put in
the error handling it might yield totally unpredictable results at
random other positions in your project. It could take you days to find
the source of the problem.
trigger_error
--------------
These are real errors you cannot ignore. But the big problem is: You
can't handle these where they occur because the only place where you can
react is a centralized error handler. There is no way to return to the
previoud code position after handling the error. Therefore, this method
is unsuitable for any errors you want to react on and then continue.
error objects
--------------
PEAR uses a standard of returning a "PEAR_Error " object if something
went wrong. Actually, newer versions of PEAR allow you to change this
behaviour and do something else (e.g. throw an exception), but I want to
explain the error object case. Well, this is mostly a poor simulation of
exceptions: You have to check if the return value is a PEAR_Error, which
is mostly done with PEAR::isError($ result). If you do this, your code
will look very much like the code you would use if you were using
exceptions (at least it won't be any shorter). But the problem of error
codes remains: You might just forget to handle the error. This time it's
a bit less problematic because you might by chance still have the
PEAR_Error object at the error position and it will tell you were it
came from because it contains an error message.
exceptions
-----------
These are a standardized way of slapping you in the face if you forget
to handle a possible error. If they are not handled, they are just as
bad as raised errors in that your app aborts and you get to see what
happened and where it happened. Nothing won compared to trigger_error
because in an error handler you have access to the call stack too. What
you win is that you CAN handle the exception where it happens and then
continue with the execution.
As previously stated: Exceptions are a controversial topic, but there
are reasons to have them.
One particular application for exceptions is in object creation: You
can't return an error code from a constructor!! If you are instantiating
a database connection object and your DBMS is down then you will still
get an object that just won't work. If you want to check for this you
are forced to call a method like $db->isOK() or suffer later when you
try to use $db in vain. Using exceptions you just don't let the object
creation happen; you throw an exception in the constructor. No database
object, no checking required, no further possibility of falsely
believing everything worked as expected.
OLLi
--
"I can be naked in 20 seconds. That includes travel time."
[Susan, DH 204]
