Re: Error codes vs. exceptions
"mike3" <mike4ty4@yahoo.com>
So where could I get examples of _well-written_, _well-designed_,
_smell-free_ error handling in a _non-trivial_ program?
Why would you need examples?
K-PEX-ians would likely say that any inelligent being is well capable of
telling right from wrong -- you even demonstrated it in the initial
message,
so all you lack is self-confidence. ;-)
What are "K-PEX-ians"?
A typo :( I meant K-PAX-ians. http://www.imdb.com/title/tt0272152/quotes
I just looked at the page, it has the quote right at the first spot. :)
You see the noise and repetition caused by mis-application of a method.
So
just think the alternatives and chose the one that has least of those
problems.
What if one of the alternatives that looks good is something often
considered
"bad"? Like a global, or a goto?
Considered by who? As we are at it, do you actually believe the goto-bashing
morons?
In C, hosed of other tools, goto has mainstream use for the very topic we
discuss. Functions have double or one-and-a-half exit. The if( ) invocations
checking the status do a goto error_exit or goto cleanup.
Creating the best of what can be done for correctness, preserving the
maximum of readability. Certainly still far from the ideal.
And it is quite easy to put the alternatives side by side and watch
defenders of the "no goto" way to sweat explaining how the extra flags,
extra assignments, extra lines, duplicate code -- or the MACROs to mitigate
it should be considered better. You don't even need to ask the question
"now explain me, who is here really get confused by seeing that goto
cleanup or cleanup: -- and why we keep paying him?
Anyone can shout good or bad -- it has little/no info, skip directly to the
explanation part. If it's missing or speculative, well, guess what. ;-)
And also, perhaps I'm not necessarily so interested in rigid rules as
to
understand better how to make "good" code.
Write alternatives and read them back. Or show them for review.
You mean write the code and then read it to yourself? Write a method,
sniff it with your own nose?
Yes.
And no, you can't have a general solution for the concrete problems. No
silver bullets. You must think alternatives for every particular case.
I didn't think so. I was looking more for just what needs to be
considered.
Elswhere it was mentioned that writing exception-safe code is hard, maybe as
hard as correct MT. The last part is certainly not true, but there are some
gotchas, and you must be aware of them. Indeed it is easy to make some naive
mistakes that craete nasty bugs.
So before you jump on exceptions read at least the first too books of Herb
Sutter.
On the bright side we can state that a code that is not exception-safe and
needs adjusting is very-very likely wrong anyway, and needs the same
transformation for different reasons even without exceptions.
Basicly you need to look for code that has side effects avoid having too
many (mean more than 1 :) side effects in an expression.
A big problem is that I seem to find a lot of conflicting information.
Just like the three blind guys go into "contradictions" describing the
elephant...
So does this mean the positions "use only exceptions" and "mix error
codes with exceptions" and "use only error codes" are not as
contradictory as they seem?
Sure. The main guide is "do the right thing -- and for the right reasons".
May seem vague but works out in practice, and if you have a culture of code
reviews and team retrospectives (based on true openness) you even avoid
getting blinded by your own light. ;-)
Some say use exceptions, others say use codes, others say use
exceptions only when "exceptional", otherwise presumably use codes.
But codes have a number of problems of their own (see the thread
on comp.lang.c where I deal with C where there are no exceptions
and only codes).
Heh, is there a point in that discussion? It should be vwell known, that
you
can have only two kinds of C code: the incorrect and the unreadable.
Exactly due to the lack of sensible centralized error handling, and
auto-cleanup. So any code that actually checks the return codes (that in
C
have no realistic good alternatives) will be infested with all the checks
and cleanup actions. To a level you can't see what should go on.
Does this mean that C sucks?
Of course it does. What doesn't. Quoting Stroustrup: "The major cause of
complaints is C++ undoubted success. As someone remarked: There are only two
kinds of programming languages: those people always bitch about and those
nobody uses." It applies to C and many others.
C sucks for having very few tools, so you must spread complexity in the code
itself. Other languages suck because they have many tools, so the user must
learn them, use them correctly, and deal with the fact that the same thing
can be done n so many different ways.
Did you try the 'five whys' method?
So then you should ask "why? why? why?" to ALL these rules -- use
only exceptions, use exceptions only when "exceptional" with error
codes for everything else, use only error codes, never make a method more
than X long (20 lines, one screen, etc.), never use a global, never use a
goto, avoid singleton, etc.?
No, you ask one why on the rule, and keep asking why on the answers you get
recursively. Until you reach the roots. (Or discover there is no foundation
really just thin air.)
Huh. Did you ever hear people saying that any guideline is only as good
as
you understand its rationale?
I met a plenty of those "NO" guys, asked the 5 whys, most started to
sweat
blood right at the first, or didn;t even understand what "why" means and
if
he supposed to provide some answer.
Isn't that a BIG problem if "most" fail to understand these reasons?
Sure it is. But that't the fact of life. Software creation (I'd not call it
engineering) is still in the wild west era. There are no quality controls on
any level -- especially on the consumer side that would drag the rest. Big
majority of the projects just fail to deliver or by delivery uses up 3 or
more times the budget and/or time. And the result is not pleasing.
I recall a fine red book from almost 30 years ago -- Ashton Tate's intro to
dBase III, where uncle Fred created the program to cover his fish-selling
shop. Using this shiny new tool, and reading this simple manual. And it was
a good book, I certainly could use it to write the programs just as
expected. But uncle Fread will not and can not. Ever since, no matter how
many shinier tools were created and how computers enetered the everyday
life.
Writing correct programs is just hard, and few can do it. The majority of
people involved in the industry can onjly provide stuff the "looks like
working" at best, or dragging down the overall project as baseline.
But shhhh, the Political Correctness cops say we are not supposed to reveal
that, and pretend that everyone is equally good ignoring all the
counter-evidence.
So I keep suggesting to ignore the loudness, and check only the rationales
given.
Does this mean I should get to work spending a lot of time memorizing
rationale?
Memorizing? No, a good rationale will just conquer your mind, and will pop
up as soon as you see something contradicting.
you need to read, study, understand the rationales, accept or reject them
for yourself. The rest just happens.
Where can I find detailed rationale for all these rules --
no long method,
no global, no goto, exceptions vs error codes, etc. so as to be able
to know
enough rationale to pass the "5 whys test"?
The Sutter/Alexandrescu book I already mentioned is a fine start.
Those you san send directly to <Censored> not passing GO and not
collecting
$200.
OTOH look how true mentors work. Like HS+AA with the book 'C++ Coding
Standards'. For every item it is told why it's good, why bad, what are
exceptions, and provide a deal of references to more detailed explanation.
And you will find that those references have similar quality.