Tale of debugging and programming logic in c#/sql

Just finished off a production .NET web application written in c#.

I set up a error handler in the global.asax which is triggered to iterate
through the error stack and send it and other information to me in an
email. This gives me logging and alerting and a record of usage ( by
sending time ).

After deploying the application I noticed intermittent errors in the Page
Load event after the user logs on. I wasn't every user, but the errors
occurred all day long. My error handler email shows two session variables
and the user name as well as the trace. The error was: Object reference
not set to an instance of an object. If you've done any .NET, this can
mean an uninitialized or null variable ( among other things) that is being
used in a method or cast that a NULL cannot be used.

I was puzzled. This would have been the very first thing after Forms
Authentication -- and obviously, I would run through that step many many
times both in the VS IDE and in QA. Occasionally my QA engineer would see
the problem, very infrequently, and report it to me. But then I could
never reproduce it. And by the time I got back to him and asked him to
show it to me, the problem didn't reappear.

Then I noticed something. All the user names were multiwords -- that is, I
was always testing with something like /jb/ or /jbailo/ as the user name.
In the error messages, the user name was Mary S. Rutherford. And the spec
said we would allow for a full name as the username. Aha! I have found the
bug -- spaces and periods. To test, I entered my name, John A. Bailo and
it threw the error. So I set up a parsing method to remove all
non-alphanums from the user name. Testing again, I saw that my fix worked
and I pushed it to production. I was anxious to find a fix, and I didn't
do full testing. The login page was written poorly -- it was from an
earlier release of the web application -- but we didn't have time to change
it. It used a composed String for the SQL command rather than a
parameterized query.

Waited a few hours and watched the errors. Nope. The production site was
still generating errors. What was it, what was it??? Finally, I loaded up
VS.2003 and set some breakpoints. Instead of using my name, I used one of
the names from the customers. BOOM! Now I saw it. The login page does a
INSERT if its a new user ( and a lookup if its a returning user). When the
INSERT statement ran with the user's name, it threw an error that said
'String or binary data may be truncated'. That's it. The spaces aren't
the problem -- it was that the user name was TOO LONG! Checking the
database, I see that yes, the username field was nchar(10)! Inserting a
longer name threw the error.

So what happened was: there is a Session variable that is created once the
user authenticates or creates a new login name -- it is based on an ID
number generated in the database once the user's name and password are
inserted. The INSERT never completed and so caused the session variable
to be NULL and the first time it was accessed by another method -- it threw
the error.

Why was I fooled? Because John A. Bailo with the spaces and period removed
is JOHNABAILO -- 10 characters!!! I /fixed/ the problem, but locally --
not globally; only for people whose whole name is 10 chars or less after
removing spaces and non-alphanums!

Oh, and why didn't the error email show the actually error? Because I had
used a try/catch block for the login INSERT statement -- and I didn't put
tracing or logging in the catch -- thus the statement threw an exception
and proceded on its merry way -- and later on in the code when the missing
session variable threw an error -- I had no idea what the actual cause was
-- though I spent a week trying to fix it with system level fixes such as
explicit garbage collection and tweaking the IIS server.

Oh -- the logic of programming...

--
W '04 <:> Open