[
Lists Home |
Date Index |
Thread Index
]
> Karl Waclawek scripsit:
>
> > 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.
>
> Since an AllDoneException is basically stateless, you can employ a singleton
> and bury the cost of allocating it in the general startup overhead.
AllDone is not necessarily stateless, you may want to pass details back,
as to why the parser was stopped early.
Even if stateless (the exception), you still have the cost of catching it.
Setting up a try..catch just for getting back a result?
Looks like hacker code to me. I just can't understand how
this improves the code. Readability certainly isn't improved.
Understanding suffers too.
> > 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.
>
> You did, but low or high, return codes are a botch.
Well, we have to agree to disagree. Both have their place,
and that is out of the practical experience of writing and
maintaining production code.
> > 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.
>
> A newly allocated exception, as I suppose. It should be quick to determine
> the numbers for a singleton exception, too.
They are only marginally better.
It seems Delphi is already good at repeatedly re-allocating
the same object.
> But fundamentally this is a benchmark, and execution speed on a benchmark
> is no indication whatever of execution speed of a full application running
> on live data.
So, benchmarks have no meaning? Rhetorical question.
You must have realized that I focussed on specific use cases.
But actually, I got side-tracked by the performance issue,
the more general problem is that using exceptions for the normal
control of program flow makes code less readable and understandable.
OTH, to have a different syntax and style for the exceptional case
is not only more readable, it also separates program logic from
borderline cases, improving one's understanding of the code.
Karl
|
