Common Sense 4 Common People

Fun with Vista blundly contradicting itself

Last night I came across a dialog box in Vista that I found to be incredibly funny.
Take a look (I hope the text is readable in the 30% reduced image, otherwise click on the image to view full size):

Clearly enough, under the checkbox Vista claims "Scheduled defragmentation is disabled".
Then on par with the "Defragment now..." button Vista also claims that "Scheduled defragmentation is enabled". Cute :-)

How can you reproduce this? Just open this dialog box and if "Run on a schedule" is checked then uncheck it and without closing the dialog or pressing Apply click "Defragment now...".
When defragmentation completes then Vista displays the "Scheduled defragmentation is enabled" message.

Obviously, since the unchecked checkbox has not yet been committed, the code that sets this message reads the currently stored value for the "Run of a schedule" flag from somewhere in the system and then proceeds to inform us that it is still enabled, although the same information is supposed to be already available elsewhere on the same dialog box (basically this is the real bug in the dialog).

Really it is such a silly mistake, on such a commonly used dialog (or is it not) that I would have expected their testers to notice... Makes me lose some confidence even on SP1... Maybe they get it right on SP2 with this OS.

Have fun!
Dimitris Staikos

Error Handling Crimes

Hell, I am furious! I come to work on a bloody Saturday, to review some code so that we can release our new product on time and I stumble twice on one of the most basic coding crimes when it comes to error handling, each done by a different developer.

I know it's natural to make errors, that's why I do the code review in the first place right? Absolutely! The reason that I am furious is that one of the two instances of this crime is long ago commited to our product (an SDK) and thus I cannot correct it... because... I will break backwards compatibility. Damn it!

The other one is not released yet, so it's just a human error; we'll just have to update about 70 calls to some internal function and we are done.

So what exactly is this crime I am talking about?

Simply put, it is a CAPITAL OFFENSE to convert an error code to a boolean Success_or_Failure flag.
A variation of this crime is to convert a rich error code into something like E_FAIL (in the COM world).

In real life, most programs cannot do much in the face of errors, other than (a) not crash (b) let the user know what went wrong.

In real life, when something goes wrong the user will immediately contact technical support. So imagine being the tech personnel, having a frustrated and often angry user telling you "Hey, I tried to do such and such and it fails with the error E_FAIL (Unspecified Error). What the hell is going on?".

Exactly my point! What the hell is going on???? How is our tech support team supposed to provide decent technical support if we don't know exactly what error occurred?

Most developers I have encountered in my career so far don't have the proper understanding and respect for error handling code. They want to write the REAL code not the error handling crap (or heavens forbid... the documentation).
They don't understand or just don't want to realize that in solid systems the error handling code can be up to 50% of the code. Yeap, that's FIFTY percent. And if you don't write it properly then you are NOT doing 50% of your job. Think a little bit about it.

Moreover, in most cases you don't write the error handling code for your end user, you write it FOR YOUR OWN SHAKE, to make YOUR LIFE easier when something goes wrong to the user. Because as sure as death and taxes are, things going wrong to the user is a certainty.

OK, now that I've had my fair share of whining I am not furious any more... Back to business :-)

Have fun!