[openbeos] Re: Asserts?
- From: Scott Mansfield <thephantom@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 5 Oct 2002 22:49:40 -0700
On Saturday, Oct 5, 2002, at 08:55 America/Los_Angeles, Michael Phipps
Honestly, I'd be fa-bleeping pezzed off
!!! Such strong language!!! ;-)
FYI: written vis-a-vis Johnny Dangerously. The english language is one
of my hobbies.
Not trying to be confrontational, just engaging in lively discussion
with some of my peers. :-)
I love it!
Good stuff, bro. Let's continue on then, hmmmmmmm?
First, at the risk of stirring things up a bit more, a little history
might be in order before revealing the motive behind the original
In a previous job, it was policy to always throw from a method when an
error ocurred. Yes, my fellow developer, you read this correctly.
Return a status value? "Heck no, we gotta throw" was the official
party line. (Said in the same 2/4 cadence as the 1960's and 1970's
protester chants -- I am old enough to remember this era in case you're
wondering; not that it matters anyhow.)
The management's directive being, to the developer: "you must return a
string embedded in your exception describing the nature of the error,
and corrective action, which can be presented to a client in a dialog
box, and not just a meaningless number which will generate a support
call. Bubble out of the failure condition using try/catch blocks all
all costs." From that statement you can surmise three main points
(there are more, and you would assuredly be correct on all counts):
1. The project manager knows this much <holds fingers apart just a wee
bit> technically, but thought he knew this much <stretches arms the
full two meter span>. This is the bombastic way to say "F-ing
clueless!" A prime candidate for Dilbert's Pointy-Haired Boss award if
ever there was one.
2. Exceptions were the tech-support "mode du couture" (please pardon my
jacked-up French). It was general policy that two or three lines of
obscure programmer prose were enough to prod even the most clueless
customer in the right direction to keep from over-working the support
folks. Yeah, right! Next?!?!
3. The code never made it to production status.
It was amusing to watch 30 or so of these ::ahem:: helpful ::ahem::
dialogs, and 500+ entries in the NT event log, generated when this
program would do something as simple as answer an incoming call. Our
QA department, bless their interpid souls, had the proverbial "patience
of saints," sure wish I could bring the whole lot of 'em to my current
This, my friends, was a 2,000,000+ lines of C++ code behemoth
"designed" to be a full-blown buzzword-compliant telephony application
suite running on 'doze NT 4 server. It was intended for deployment at
a telephone company's CO. If the above notion frightens you then
consider this: three of the MAJOR telcos in los Estados Unidos, along
with two MAJOR telcos in Europe were ready to buy this beast. Thank
whatever diety or higher power you ascribe to that this gem never saw
the light of day or your telephone service would be exponentially worse
than it may be now. :-P
Or, the short version of the above diatribe for the lexically
challenged of the geek literati:
"Damnit Jim, I'm a doctor, not a <insert occupation here>"
--Dr. "Bones" McCoy
"Lords of Light!"
From that fine kettle of fish I took away this very simple rule of
thumb (amongst others): "exceptions are for exceptional conditions."
'K. Enough of that madness, hopefully you now understand where my
paranoia and apprehension stems from.
I guess I should have explained some of the conditions I would consider
candidates for assert()s, and why I asked the question in the first
place. Duh, Scott. Duh. My apologies to those who are scratching
their heads going "Huh?"
To restate the obvious, there exists in all the Be/OBOS classes that
I've seen to date, an InitCheck() method accompanied by the suggestion
that said method should be called after construction to make sure that
construction, and by inheritance (pun intended), class attributes were
I can see two major points of failure with this approach (there are
likely others, YMMV):
1. Construction fails, fInitialized (or some lexicographical
equivalent) is false, but in many cases the object is still
instantiated from the implementor's point of view.
2. Constuction succeeds, but the class' attribute default values as set
by the parametric ctors are not sufficient to carry out the class'
In both cases the end result is that I now have an instance of a class
that is useable through the usual venues, but the class' attributes are
in an unknown, possibly semi-initialized state--said instance is not
As a side note, InitCheck() cannot guarantee invariance, either. Glass
Elevator stuff perhaps, but noteworthy IM<not so>HO nonetheless.
Now, suppose I blithely ignore InitCheck() and use one if this suspect
class' accessors? I might get back good data, I might not. It's a
This is a great segue to another of my programming maxims: "If one, as
a developer, can think of a way to get at bad data successfully, then
it *is* going to happen and bite you in the posterior down the line."
To prove this maxim all I ask is that you use Windows(r)(tm) and
perchance Internet Explorer for a little while. :-)
Keeping in mind from an earlier posting where I assert that assert()s
(again, pun intended) are "stupid programmer error" traps, this seems
like a likely candidate for assert()'s.
What I am asking is if it would be, within the OBOS realm, proper and
prudent to assert() from an accessor if the class is not properly
initialized (i.e.: InitCheck() would return B_ERROR)?
To make a laterally thinking, generalized statement: we can't/shouldn't
assert from mutators because these are used during construction (unless
we set an "InCtor" or somesuch flag somewhere if we're in a ctor, but
that's beyond the purview of this missive).
Note that I chose not to do this at the moment because the general
consensus (by looking at the OBOS code base) is that we generally allow
our consumer to shoot themselves in the foot with aplomb. :-)
Please understand that I'm not trying to beat the issue to death.
On a different topic my original posting has generated a lot of
off-list responses, thanks to all for your kind words both on- and
off-list. I appreciate it. :-) In the four other open source projects
I've worked on this kind of comaraderie just didn't exist. My
heartfelt thanks to those who took the time to write a personal
response, and apologies for not replying in kind.
Other related posts: