Amazon.com Widgets Even Hints Can Reveal Errors

Even Hints Can Reveal Errors

By Nick at February 23, 2013 06:00
Filed Under: Software Development, Delphi

Introduction

I hope that you all know that when you do a full build on your Delphi project, you should never allow hints and warnings to remain in your code.  Warnings, in particular, are an indication that something is going on that you almost certainly don’t want to be going on.  But what about hints?  Hints can’t really be a problem, can they?

Well, yeah, they can definitely point to something happening that you don’t want to happen – or in the case below, of something not happening that you do want to happen. 

The Situation

Let’s say you are maintaining an older Delphi application and you run across some code that looks like this:

begin
  Screen.Cursor := crSQLWait;
  // A bunch of database code that might make
  // the user wait
  Screen.Cursor := crDefault;
end;

And naturally you think “Oh my, that will never do.  What happens if an exception occurs in that database code! The cursor might be stuck!  That needs a try…finally block around it!”.  And so you do the following:

begin
  Screen.Cursor := crSQLWait;
  try
  // A bunch of database code that might make
  // the user wait
  finally
    Screen.Cursor := crDefault;
  end;
end;

And that’s better, but something is still nagging at you, and it suddenly hits you – "what if the cursor wasn’t actually crDefault to start with?  Shouldn’t you restore the cursor to whatever it was before you started?”  So you are feeling a bit cocky and you proceed with a bit too much haste and you do this:

var
  OldCursor: TCursor;
begin
  OldCursor := Screen.Cursor;
  Screen.Cursor := crSQLWait;
  try
  // A bunch of database code that might make
  // the user wait
  finally
    Screen.Cursor := crDefault;
  end;
end;

But like I said, you are feeling a bit cocky, and you think “I’ll be this is all over the place” and you search for similar code patterns and you are right and you go off and fix this “omission” that is scattered all over your codebase.  Things are great, right? 

Finally you compile and there is a <shudder> hint in your code! 

[dcc32 Hint] Unit5.pas(29): H2077 Value assigned to 'OldCursor' never used

and you’re like “Whaaat?  It’s just a silly hint, who cares!”.  But of course, your conscience is nagging at you, and you remember that Nick told you to not allow any hints or warnings, not even stupid hints like this one, and you suddenly realize that your code has an <another shudder> bug in it and it is not doing at all what you wanted and intended for it to do.

And of course, you fix the subtle bug of forgetting to actually set the cursor back to its original value:

var
  OldCursor: TCursor;
begin
  OldCursor := Screen.Cursor;
  Screen.Cursor := crSQLWait;
  try
  // A bunch of database code that might make
  // the user wait
  finally
    Screen.Cursor := OldCursor;  // <--- forgot this part
  end;
end;

And then you think “Dang, that Nick dude was right!  Hints really can indicate problems”, and you never let another hint slide for as long as you live.

And of course, I should say that I totally made this scenario up, and that I would never, ever, ever do anything like that.  Nope, not me.  Nope.  No way. Neeeever happened.

blog comments powered by Disqus

My Book

A Pithy Quote for You

"There are no such things as limits to growth, because there are no limits to the human capacity for intelligence, imagination, and wonder"    –  Ronald Reagan

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.