Re: Exception Misconceptions
In article <668a7a4b-a2ee-4999-b3bc-5020bdac17ed@k4g2000yqb.googlegroups.com>, James Kanze <james.kanze@gmail.com> wrote:
On Dec 18, 8:31 pm, Brian <c...@mailvault.com> wrote:
On Dec 18, 2:29 am, James Kanze <james.ka...@gmail.com> wrote:
On Dec 17, 8:11 pm, Brian <c...@mailvault.com> wrote:
On Dec 17, 12:27 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
The machinery isn't that complicated. After all, you
need to be able to walk back the stack in other cases as
well (e.g. in a debugger---and what compiler doesn't
come with a debugger). The alternatives are relatively
expensive, and some people do choose their compiler
based on benchmark results (and those benchmarks rarely
test the performance when an exception is thrown). For
better or worse, performance is an issue for compiler
vendors---lower performance means less sales.
When buying a car I care about how fast it goes from 0 to
60. There's flexibility about the range for that with me,
but if a car is two to three times slower than others in
that regard, it's a big red flag
So you won't consider cars like the VW Golf, since a Ferrari
does accelerate two or three times fasters.
Actually, I'm sure you didn't think that statement out.
Performance is only one of many issues---I'd guess that
correctness would be the most important one (but even
there---correctness is only important for the features you
use). Or even availability: early implementations of
exceptions used the slower mechanism because they could get
the implementation out the door quicker that way. And so
on.
I'm not arguing with that, just saying that with the software
in question, both are free. If price/cost isn't a factor, I'd
definitely take a Ferrari.
You don't have three children:-). I wouldn't mind having a
Ferrari, either, but for day to day use, there are more
practical cars. Regardless of price. With three children and
two dogs, a van beats a Ferrari hands down. If you really live
out in the wilderness, with only dirt roads, you'll probably
prefer a Jeep. And if you have to drive and park a lot in
Paris or London, you'll want something small. As with software,
there's no silver bullet.
With regards to exception handling and C++ (to get back on
subject), if some of the early implementations of exceptions
used slower mechanisms than is considered necessary today, it's
generally because it was a question of supporting exceptions now
with the slower mechanism, or supporting them in two years time
with an optimal mechanism.
I am not going to comment on exceptions.
This issue is done to me. I know EXACTLY how to architect
and strucuture my code so that it works like a tank,
no matter what happens. It is a subtle mix of return codes
and exception mechanism, but there IS a solution, and it
is all implemented in one of my Java programs, the main
program I use.
Similarly, with regards to optimizing application code: you've
only got so much time to write it in, so it's often a question
of making it take 5 milliseconds less time (over an hour), or
adding a feature.
Well, to me, optimization is indeed one of the major criteria,
except I view optimization from the stand point of architecture.
There are different ways to structure your code,
or architect the system.
The major criteria for me are:
1) Minimization of the size of executable,
which indirectly translates into correctness of your code
and flexibility of your structure and program architecture.
2) System architecture.
Structuring the program is more important to me than
tweaking some routines to get the most bang for a buck.
3) Expandability and extensibility.
No matter what you write, you will have to forever expand it,
add more features and bells and whistles.
If your architecure is not "correct",
it is going to be a royal pain on your rear end to add
something QUICKLY.
I can add totally new functionality to my code within minutes,
no matter what i want. Typically, a MAJOR restructuring
takes several hours. At most a day or two.
So, I can expand my code as fast as I get some new idea
or feature.
4) Portability.
A tough one. Forget about it in the C++ world.
Such a major headache, that it is realistically undoable
unless you maintain several code bases.
With Java - a pice o cake. Non issue.
5) Robustness.
And THAT is where these nasty exceptions come in handy.
You'll never be able to write a stable code, and I mean
TRULY stable, if you do not use exceptions.
Otherwise, your code is going to be such a huge file of
conditional spagetti, that only God, omniscient, will be
able to see the net result.
Exceptions are a MUST.
But...
No need to get wild on it.
Exceptions should not be a part of your logic.
After all, what guides your program in 99.999% of all cases
is those nasty ifs and buts and not "something does not work".
So, exceptions should not be a part of your underlying logic.
They are your defense system against ANY kinds of problems.
You can NEVER assume that ANY operation is going to complete
without problems. In the middle of some routine, you may
loose power, just for the sake of argument.
That means, that once you restart your program, and it was
in the middle of doing some heavy duty processing, you should
be able to recover and continue on, if at all possible,
even in principle.
6) Never, under ANY condition, ignore ANY errors, even if
it looks like it will never happen and your code works fine
as it is.
Unless you handle the most inconceivable thing,
such as seemingly utterly meaningless return code,
your program eventually and inevitably will crash
one of these days.
7) Always complete your code.
Once something is written, it should be written to the state
of completeness. Meaning. You should be able to rely on that
code no matter what happens and no matter what kind of crazy
thing you may invent in the future with your system.
The complete code is easy to extend and restructure.
8) Program is a system.
This is probably the #1 item on the list.
Any more or less useful program is a SYSTEM.
It is not just a pile of code.
a) The most important system parameter is what?
Well, stability.
If system can EVER crash, you are dead and your program
isn't work a dime more or less.
b) The system is not a dissasociated set of ideas,
methods and routines.
It is an organism, alive, just like anything else on this
physical plain.
Any system has subsystems, performing diferent sub-tasks
to accomodate the living whole.
Subsystems, in their turn are also systems.
There needs to be a well thought out architecure
to minimize the number of subsystems and maximize the
bang for a buck.
Subsystems need to communicate with each other
and provide "sockets" for relating with other subsystems
or the master system. The best way to assure that is to
do all the communications via master system, which
is the main module of your program.
Every subsystem is guaranteed to know one thing
and one thing only: there IS a master system it serves.
It can rely on existance of it.
All interfaces should be constructed via master system.
No subsystem should attempt to communicate with the other
subsystem, or even know of its existence, if at all possible.
This way, your program architecture and structuring
of your code will be automatically optimized in most
cases and situations.
Do not worry about performance first. But keep it in mind
no matter what you write.
The original ideas need to be fundamental enough to
provide a significan enough benefit to even bother about
implementing it. From that standpoing, the modelling is
the most critical thing at this junction.
Once you implement your model and test it to sufficient
degree, then you will be able to see the weak points
and those things you did not think about initially.
At that point, you can start thinking about optimization.
But not before it.
Never start writing the most optimized code from the
fist take. Becaue it is not even clear it will become
a bottleneck in the final system.
Just tweaking things for the sake of "performance",
is the same thing as blind leading the blind.
The end result is the abyss.
I think all really competent computer scientists are purists,
Good. Keep them in museums then.
If someone has time to look at that stuff before the
end of times, and we have about 2 generations to go
before REAL hell will rage on the planet Earth,
abused to the hilt.
Get the hint, mr. "expert"?
and would like for every line to be
"optimal" (foremostly in elegance and readability, but also in
terms of performance).
Fine and dandy.
In THEORY.
In reality there is such a thing as "bang for the buck".
The "economics" of anything created.
The "purity" of code is more or less a mental masturbation
excersize, and I am not trying to be insultive.
I also keep in mind the code purity.
What I can tell is is this.
The 3-5 meg programs I wrote do pretty much the same thing,
if not better, than a typica half a gig sized bloatware,
written by "top guns".
That is ALL I need to say about "optimization"
or "purity of code", or "correctness", no matter what you
imply by it, and what scope you are referring to.
I also think that all really competent
software engineers know how and when to make engineering trade
offs.
I have to agree on this one.
Enjoy the ride.
:--}
--
Programmer's Goldmine collections:
http://preciseinfo.org
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.