What do you mean, “why are the websites down?” – I asked as I turned to look at my boss, in confusion.
“They’re not down.“
“See, they’re …”
It was the early 2000’s and I was nervous about what I had built – a new and ambitious application with a new language runtime and a new development platform.
Initially, there was a sigh of relief when I saw my work on the production website. But that was quickly overshadowed by the horror of what I now saw.
An error – right there on screen, where my website should be – was telling me that the app couldn’t connect to the database.
I restarted the app, and it connected.
WHEW! That was a close one.
A moment later, the site was down, again.
I checked the database management console, and saw that all available connections had been used, and none of them were releasing.
My connections being eaten up?
They aren’t closing, or recycling in the connection pool?!
I didn’t understand. I had my connection “.close()” method right there – just like always – right after my return statement…
It took almost 2 hours to figure out the mistake I had made
… and it was a mistake you can probably guess, from my description above.
The “return” statement in VB.NET exits the function immediately. The database connection would never close.
“How stupid is that?!” I thought.
“VB6 didn’t do it that way. Why would they change that in VB.NET?!”
Fix It. NOW!
No time to figure out why VB.NET is different – too much pressure…
Boss breathing down my neck; customer support holding back the horde of angry distributors; C-level execs asking why the sites are down!
I found every database connection “.close()” and moved them one line up.
I deployed. It worked.
The sites were up, stayed up, and I slowly started to breathe.
Then my boss called me into his office.
Looking back, I know my mistake was one of assumption.
I assumed the language I used for that app would behave the same as the previous language in which I had worked.
They shared a similar syntax, after all. I thought they were the same.
It is familiar in the same way VB.NET was familiar to me, back in those days, because I had worked in VB6, previously.
In C#, “this” always points to the object on which a function is defined.
Misunderstanding the language fundamentals.
A lack of knowledge in the fundamentals of any language is dangerous, at best.
You may end up with code that looks like it works, but won’t stand to the pressures of a production deployment
I found that out the hard way, with VB.NET, all those years ago.
Ultimately, learning the fundamentals of any language is important.
With behavior that looks like C# in some circumstances, but behaves in what look like unexpected and unpredictable ways in other circumstances, “this” is easily the most notorious feature of the web’s darling language.