[
Lists Home |
Date Index |
Thread Index
]
> Karl Waclawek scripsit:
>
> > Maybe that is different for Java, but in general this is simply wrong.
>
> If you mean "in C++", say so, not "in general".
No, I do mean: to say that using exceptions for common program flow
control is what they are meant for, is not true in general.
> The IBM implementation
> of Cobol made procedure calls very expensive, and most Cobol programmers
> never wrote a subroutine throughout their careers, and only invoked them
> for the sake of DBMS access, where they had no choice. That didn't make
> procedure calls in general a bad idea.
>
> > Apart from that they are expensive in most languages.
>
> Expensive compared to what? If every procedure must return status, and
> every caller must check the status and decide whether to itself return
> status or carry on, your code size enlarges immensely and so does your
> execution time.
Not compared to exceptions. Memory allocation and deallocation
is very expensive across most languages. You can alleviate this somewhat
with a smart garbage collector, but only to a degree.
And also, checking numbers is extremely fast on today's CPUs.
The only thing to be concerned here would be call overhead.
> The alternative is to do what most C programmers do,
> ignore status returns and carry on. We all know where that leads.
I think I said something about using status in low level code
and leave the decision about exceptions to high level code
with sufficient context to make it.
>
> > And you have to trap them in your app, since you might not actually want to
> > terminate the routine where the parse call returns to.
>
> We were discussing the use of exceptions precisely to terminate parsing.
Exactly, but then you want to continue parsing another 2000 files
in the same loop. We even added a Reset function to the Expat parser
(instead of Free and Re-Create) to cater to these kinds of use cases.
> > Well, we (a group of programmers) ported SAX2 to Delphi.
> > On Delphi the idea of using exceptions for regular program flow control
> > is just not right. Same in C++.
>
> You may be right: I don't know either C++ or Delphi particularly. But I
> notice that Stroustrup took the trouble of making sure exceptions got into
> C++, which means that he must think they are good for something.
Yes, they do and I use them all the time. That is, for dealing with the
exceptional cases.
> > And like C++, Delphi is sometimes used for speed, meaning that
> > one takes care about memory allocations. Exceptions are too
> > expensive from that point of view, which matters if the program
> > is meant to continue, and matters less if the current context has to
> > be terminated.
>
> It is well known that claims of efficiency and inefficiency mean nothing
> unless backed up with numbers, for programmers' intuition on the subject
> is notoriously in error.
This is no intuition. I can whip up a quick demo in Delphi
(I already did - took 5 minutes) which shows that passing a Boolean result
up from a 5 levels deep nested procedure call executed in a loop is at least
100 times as fast as throwing and catching an exception for the same purpose.
I can post or e-mail it if you really want to see it.
Karl
|
