[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 wrote:

Honestly, I'd be fa-bleeping pezzed off
!!! Such strong language!!! ;-)

LMAO :-D


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 missive.

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 employer. :-)

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:

"Great Maker!"
    --Londo Mollari

"Damnit Jim, I'm a doctor, not a <insert occupation here>"
    --Dr. "Bones" McCoy

"Lords of Light!"
    --Thundarr

"Odds bodkins"
    --Unknown

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 set "correctly."

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' intended task.


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 invariant.

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 crap shoot.

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.

Cheers,
Scott Mansfield


Other related posts: