What is the difference between exceptions and simple error handling

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? For example, I could suppress my
functions using the @ sign and then use an if statement to check if
they returned false or not. Similarly, I can also return various
integers, like -4 and -5 for errors, and check those.

Article: http://www.talkphp.com/showthread.php?t=1478

As you can see, the article gives some reasons why, but I don't think
it's quite convinced me that exceptions are the way to go. I thought
maybe they'd introduce a lot more into the error handling side of
things, but I think I am mistaken. Unless I am overlooking something?

Re: What is the difference between exceptions and simple error handling techniques?

adam.timberlake@gmail.com wrote:
> 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? For example, I could suppress my
> functions using the @ sign and then use an if statement to check if
> they returned false or not. Similarly, I can also return various
> integers, like -4 and -5 for errors, and check those.
>
> Article: http://www.talkphp.com/showthread.php?t=1478
>
> As you can see, the article gives some reasons why, but I don't think
> it's quite convinced me that exceptions are the way to go. I thought
> maybe they'd introduce a lot more into the error handling side of
> things, but I think I am mistaken. Unless I am overlooking something?

Well, They give you the ability to encapsulate your error messages
inside the code that generates them, and them do something about them
outside. It makes a neat script , for one thing.

Re: What is the difference between exceptions and simple error handling techniques?

adam.timberlake@gmail.com wrote:
> 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? For example, I could suppress my
> functions using the @ sign and then use an if statement to check if
> they returned false or not. Similarly, I can also return various
> integers, like -4 and -5 for errors, and check those.
>
> Article: http://www.talkphp.com/showthread.php?t=1478
>
> As you can see, the article gives some reasons why, but I don't think
> it's quite convinced me that exceptions are the way to go. I thought
> maybe they'd introduce a lot more into the error handling side of
> things, but I think I am mistaken. Unless I am overlooking something?
>

Please don't multipost. Crosspost if you must post to multiple newsgroups.

Answered in alt.php.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: What is the difference between exceptions and simple error handling techniques?

adam.timberlake@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]

Re: What is the difference between exceptions and simple error

Thank you for your responses. I think I'm getting close to realising
their true purpose. Incidentally, how do I cross-post?

Re: What is the difference between exceptions and simple error handlingtechniques?

adam.timberlake@gmail.com wrote:
> Thank you for your responses. I think I'm getting close to realising
> their true purpose. Incidentally, how do I cross-post?
>

Well, to start with, get yourself a real newsreader. This is usenet,
and Google Groups is just a poor interface. There are much better ways
to read newsgroups. Even Outlook Express (shudder) is better than
Google Groups.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================