When is a bug not a bug?

This sounds like the intro to a bad geek joke.  (Answer:  When it is a feature?)

But seriously, this is a valid question.  Consider the following situation. 

You have some code that looks like it should not work. But it does. The program is in production, for gosh sakes.  Works great, every day, all day, this very feature.  So you pull your hair out trying to figure how this clearly defective code does not cause a problem.

After all, one of the laws of the universe says that when something doesn’t seem right, it probably isn’t.

Usually, the cause of the “bug” turns out to be operator error, e.g. editing a stored procedure in one database, while the connection string for the web site is pointing to a different database.  Or there might be multiple copies of the source code extant, and you are looking at a version different from the one that is actually running.

Not this time.  The specific “bug” which raised this question in my mind occurred in some JavaScript I had written for a web site.  Similar situations can crop up in any language or environment.  That said, the loosey-goosey nature of JavaScript makes it especially vulnerable.

I was trying to track down a bug where some, but not all, automated e-mails were not getting properly sent.  The error message was cryptic (although in hindsight it was perfectly clear, as is usually the case) and I was exploring all avenues.   Although the problem eventually turned out to be caused by a changed password for one e-mail account, at this stage that was not at all clear.

The page which actually sends the e-mails is called ReportsPage.aspx.  It is a strange beast in that it exists only as a vehicle for a CrystalReportViewer.  However, the fact that CrystalReports plays a tangential role here is of no consequence.  For once, the problem is not with CrystalReports.

ReportsPage is called client-side by JavaScript attached to every button in the site which might want to display or e-mail a report.  That way there is no visible postback and the report just pops up in a new browser window.

The JavaScript function which actually opens the page is called OpenReportsPage.  It takes several arguments, including the name and type of the report,  an ID pointing to the specific job or client or whatever is being reported on, and a Boolean indicating if the report is to be e-mailed.  Here is the function signature in the JavaScript:

function OpenReportsPage(ReportName, ReportType, KFID, bEmail)


In addition, there is an overloaded version, which accepts a Boolean that indicates if the report requires a range of dates.   If true, then the script looks at specific controls on the page at runtime to get the actual start and end dates.  It has the following signature:

function OpenReportsPage(ReportName, ReportType, KFID, bEmail, bGetRangeValues)


The problem was that when I examined the source view of the page in the browser, I found that many of the calls to OpenReportsPage had an extra Boolean argument. And that did not seem to cause any problem.  So was this a bug or not?

Now, if you immediately know the answer to this conundrum, then you are truly among the JavaScript cognoscenti.  If so, just hold on for a moment and don’t spoil it for everyone else.

A bit of backstory here:  I learned C# before JavaScript. One of the things I quickly learned about JavaScript is that it shares many features and much of its syntax with C#, excepting the loosey-goosey stuff alluded to previously.  For example, JavaScript is not strongly typed, and variables can be whatever type they happen to be first.

I knew about optional and default parameters in JavaScript, so I could understand how a call to OpenReportsPage with too few parameters might work. But too many?  That would certainly never fly in C#.

I searched my code over and over for the missing overloaded version of the function with an extra bool.  As a matter of fact, I remember adding that parameter to the function a year or more ago, then removing it a short time later.  But if there was no version of the function with six parameters, then why wasn’t there some sort of bad behavior?

That is when I learned about JavaScript’s Arguments object and understood why this code did not break.  It turns out that not only can a JavaScript function call have too few arguments, unlike in C#, but also unlike C#, it can also have too many.  Any “extra” arguments are accessible via the Arguments object.

The point here is not a discussion of how the Arguments object works in JavaScript, but rather to answer the original question, slightly rephrased:  Is this a bug?  Is it a problem that function calls have the incorrect number of arguments, even if no mayhem ensues?

After all, you might argue, the program runs perfectly fine and does not complain about the extra, now vestigial, arguments.  Clearly, they are left over from when the function had that extra argument , and when I removed the argument from the function, I forgot to update all the calls.

In C# that would never happen because not only is it illegal, but Visual Studio will warn me and it won’t build.

I decided this was in fact a bug, because it seriously clouds the maintainability of the code. If I were actually using the extra argument, it would be a different story. But there is no place for vestigial code in any production project.


About Dan Hurwitz

A consultant specializing in .NET.
This entry was posted in Software Development and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s