"Anders F Björklund" <afb@algonet.se> wrote in message news:d7joto$tj1$1@digitaldaemon.com...
>
> Exceptions and gotos are both bad, and error codes are
> much better. And all the extra idents makes it easier?
>



Spolsky and Chen do seem to dislike exceptions.



When I first found the D site, this sentence in the Overview popped out at me in particular:



"Exception handling. More and more experience with exception handling shows it to be a superior way to handle errors than the C traditional method of using error codes and errno globals. "



I've never known conclusively whether exception handling is a good thing or not. You can search on newsgroups for plenty of discussions and debates on it, and I've done that. But what you usually see are people arguing both sides of the debate.



Given that quote above, is there some argument or evidence that anyone can point me to that would convince me one way or the other? I don't mean to start a debate right here; rather I'm asking more for references.



People will usually say "exceptions should be used for exceptional circumstances." Unfortunately this tells me nothing unless you define what an exceptional circumstance is. In some cases I think it can even be up to the calling function, not the callee, as to what is exceptional or not. So I'd like to hear a better explanation than that.



Jim

I use exception handling when I don't trust the function I am calling.

Thats the only time I use them personally.

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com

Jim H wrote:

>>Exceptions and gotos are both bad, and error codes are
>>much better. And all the extra idents makes it easier?
> 
> Spolsky and Chen do seem to dislike exceptions.

Yes, and I probably should have written that better since
it's been quoted a few times now: it wasn't *my* opinions.

I'm using either exceptions or gotos, and liking it...

> "Exception handling. More and more experience with exception handling shows it to be a superior way to handle errors than the C traditional method of using error codes and errno globals. "
[...]
> Given that quote above, is there some argument or evidence that anyone can point me to that would convince me one way or the other? I don't mean to start a debate right here; rather I'm asking more for references.

I'm not sure about others, but I'm updating C code that looks like:

foo = calloc(1,sizeof(*foo));
if (!foo)
   return NULL;

bar = calloc(1,sizeof(*bar));
if (!bar)
{
   free(foo);
   return NULL;
}

baz = calloc(1,sizeof(*baz));
if (!baz)
{
   free(foo);
   free(bar);
   return NULL;
}

foo->bar = bar;
foo->baz = baz;
return foo;

Having exceptions (and garbage collection) would surely have helped ?
The file reading code would similarly benefit, too long for an example.

Writing the above code "Pascal-style", with indented ifs and a single point of return at the bottom only makes it worse (in my own opinion).


But unless I'm horribly mistaken, that's the approach they advocated ?
(in http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx)

--anders

Jim H schrieb:
> Given that quote above, is there some argument or evidence that anyone can point me to that would convince me one way or the other? I
>  don't mean to start a debate right here; rather I'm asking more for references.

It somehow seems to me that my point has gone down in the deep bath of
sarcasm. One can have long debates on whether the locality of code
(return value checking), or separation between action and error handling
(exceptions, errorcodes) is the right way, and whether the traditional
or exception-based error-handling is easier to write or more or less
errorprone and whatnot, but there are some things which are somewhat
less disputable.

1. Traditional error handling - either of them - can make your program
in a faulty state running in rounds, stepping more and more often on the
aching toe. And there's not much you can do to notice it beforehand.

Exception handling, on the other hand, terminates the execution of the
faulty branch rapidly, and gives control to a higher level of the
calling stack, which claims to be able to handle that. If done once
correctly at the top level, i have the experience that it can hold a
complex system running. There is not much you can do wrong in the rest
of the code, except for one highly dangerous thing: NEVER allow a
destructor to throw.

2. Exception Handling has somewhat spoiled its appearence in the eyes of
many programmers by being used for example in Java for Input/Output and
other operations which are highly likely to fail, and where you might
get a soup of exception handlers, and this situation was strongly
amplified by introducing checked exceptions. Many programmers find the
net result less than appealing, though i wouldn't like to take a
position in this discussion. I would just like to state that D doesn't
enforce strong exception checking, nor does it force exceptions for
Input/Output (though it mandates them - the standard library uses them),
so i think this is something more programmers would be able to live
with, eventually seeng that exceptions are, well, quite usable too.

I am very lazy writing error handling code, so for me, exceptions have
been a wonderful thing. I only define a few spots where i can discard
everything that happened down the execution stack and give error, or
retry, or something.

> People will usually say "exceptions should be used for exceptional circumstances." Unfortunately this tells me nothing unless you define
>  what an exceptional circumstance is. In some cases I think it can even be up to the calling function, not the callee, as to what is exceptional or not. So I'd like to hear a better explanation than that.

If you think that something is not exceptional - that is, you expect
that - you just catch the exception thrown by the function below,
otherwise leave as is. In the case you catch, it is not very different
from error codes - you must somehow decide what to do. It's the other
case that is different - with traditional error handling, the code keeps
running. You should be aware, that if a sequence of operations is
somehow interdependant, the next ones will usually fail as well.

I don't think there is much dispute on the side of the callee whether it
should throw or not. A function has a specification, and in the case
that it cannot be fulfilled due to some runtime circumstance, it throws
an exception. If throwing becomes way too usual, one should consider
defining a new function differently. While deciding on the
specification, it is probably helpful to consider that a programmer
might find a function with a simpler specification more appealing to
use. I believe, for example, Phobos to be quite a success in this respect.

-eye

"Anders F Björklund" <afb@algonet.se> wrote in message news:d7uknk$199j$1@digitaldaemon.com...
> Jim H wrote:
>
>>>Exceptions and gotos are both bad, and error codes are
>>>much better. And all the extra idents makes it easier?
>>
>> Spolsky and Chen do seem to dislike exceptions.
>
> Yes, and I probably should have written that better since it's been quoted a few times now: it wasn't *my* opinions.
>

Oh, I understood what you meant---that you were sort of quoting them. I was just agreeing with you.

Jim