[
Lists Home |
Date Index |
Thread Index
]
> On Saturday 22 February 2003 05:41, Karl Waclawek wrote:
> > > 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.
>
> Well there's no fixed dividing line between exception conditions and common
> program flow. You could say that exceptions are only for truly exceptional
> conditions such as stack overflow and hardware failure, and everything else
> should be handled by error returns... but I think few would necessarily
> agree.
Not even I!
> On the other hand you could say that, in a while loop, the normal flow
> is to repeat and it's exception to escape; if the average while loop does a
> hundred iterations then it ony stops iterating 1% of the time, which is
> pretty exceptional. Then one could write loops like this:
>
> loop {
>
> ...
>
> if (command = "STOP") break;
>
> ...
> }
>
> Many languages have just that construct. "break" is a nonlocal exit, just
> like throw / catch.
It doesn't unwind the stack.
> Then you have continuation-passing languages where procedure return points
> are first class objects; you explicitly pass the return address into a
> procedure, and there's nothing stopping you from passing in several, one for
> success and one for each different kind of failure, that return to different
> points in the stack.
Now that might be a nice feature to have in the popular languages.
Which language are you talking about?
> *shrug* I think it's difficult to argue at what point a flow of control
> becomes 'exceptional'. I'm in favour of not having religious wars about it
> and just using whatever construct is most appropriate at each point in my
> code :-)
In principle I can agree.
I usually look at it that way: If an operation throws an exception
I consider it failed: Examples:
- When a constructor does it, I assume the object was not created.
Making the wrong assumption here will cause a memory leak in languages
without garbage collection.
- When I open a file, and that throws an exception, I assume it is not open,
so I don't need to close/unlock it.
From this point of view I would assume that an XML document is in error,
or an external entity could not be resolved, if parsing the document
throws an exception.
Obviously, it is not always so clear what the definition of a failure is,
it depends on the kind of operation and possibly the context.
That is why I tend to not throw exceptions in low level libraries,
since the context in which the library is used often determines if a result
of an operation is a failure.
It simply makes my programming more consistent, if the meaning
of exception is failure. And a consistent understanding is necessary
if modules with different origin are plugged together, otherwise
one could run into resource leaks, as described above.
> > 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.
>
> Is that under Windows? ISTR that Windows has to handle some part of exception
> handling itself for some obscure reason and makes it awful slow?
Java seems to be slow too. I tried the same on Kylix/Linux.
Was actually 10 times worse. So, on Kylix the ratio is more like 1000
as was reported for Java (don't know which platform).
Cannot guess as to why.
> Exeptions don't *need* to be slow. There are fast implementations.
I am curious - which ones?
How fast can they be - if the problem is inherently more complex,
then implementations tend to be more complex and slower too.
Karl
|
