Re: try, finally

["Jason Cipriani" <jason.cipriani@gmail.com>]

Ted, I can't respond to everything right now, because I somehow
managed to spend a full hour typing that last email. Hopefully some of
what you say here, I have addressed there. There are two things in
particular that I want to point out, though:

The first:

On Thu, Mar 20, 2008 at 10:49 AM, Ted Byers <r.ted.byers@rogers.com> wrote:
>  Look, C++ has a whole suite of error detection and
>  handling capability.  To use only exceptions is
>  somewhat like a carpenter having only a hammer trying
>  to hammer screws into place.  If all you have is a
>  hammer, everything looks like a nail.  But if you have
>  a set of screw drivers in your belt along with your
>  hammer, you'll use the right tool for the job.

I believe I addressed this in my recent post. Using *only* exceptions
would be a mistake. However, using error codes when exceptions can
make things a lot simpler is also a mistake. The same goes both ways,
"to use only error codes" fits into that analogy as well. There is a
happy medium, and there are some situations where exceptions are more
appropriate, and some where error codes are more appropriate. I take
the approach of using exceptions unless I am forced to do something
else, for example, the following situations:

1) Where performance is critical and exceptions have too much
overhead. For example, if I was writing, say, a function that
intersected a ray with a cylinder to use in a ray tracer
implementation (or whatever), I would certainly not have that function
thrown an exception if the ray did not intersect.

2) Where exceptions simply can't be used, such as in the boundary
conditions mentioned above (especially across C boundaries). In this
case, error codes are the best tool, and eventually they can be used
to throw exceptions at a higher level if that is appropriate.

I do not support using only exceptions. I also do not support using
only error codes. In college, my friends used to call me Jason "Use
the Right Tool For the Job" Cipriani. Well, maybe not. My original
question about SEH was in a situation where SEH was a great tool for
what I was trying to do. The book I just wrote about exceptions is
intended only to show a good example of when exceptions are a better
tool than error codes.

The second thing is:

>  You're throwing everywhere.  It is almost as if you
>  have a bad case of cyber-stomache flu.

LOL. :-) It's better than cyber-diarrhea I suppose.

> You are using
>  exceptions for flow control.

I need to address this because it is not correct. I am using
exceptions for *error handling* flow control. All error handling
involves some sort of trivial flow control. However, do not confuse
this with using exceptions for things like this:

void DoSomething (vector<int> &data) {

  int i = 0;

  try {
    while (true) {
      DoSomethingElse(data[i]);
      ++ i;
      if (i >= data.size()) throw int;
    }
  } catch (...) { }

  // do more stuff

}

NO. DO NOT DO THAT! (heh). That is *not* what exceptions are for at
all. Exceptions are for error conditions that must result in special
handling. I hope that I haven't given an example otherwise -- if I
have I didn't intend for it to look that way.

> That is not what they're
>  there for.  Eljay's brilliant description of return
>  codes (including especially his smart return code
>  objects) is a much better option.  And don't forget
>  assertions have a valid role in many cases also.

Assertions are good for stating assumptions; they notify you when your
assumptions are invalid and also double as documentation when reading
code. However, doing something like this:

FILE *f = fopen("file", "r");
assert(f);

Is *not* a good use for assert(), for hopefully obvious reasons. I
used fopen() as an arbitrary example, substitute your favorite
function instead.


I have read the rest of your reply, but I can not respond to it right
now. I apologize. But I did read it. Thanks.

Jason