Visual Basic has to be one of the most polarizing technologies of the last twenty years. No technology is at once as revered as the tool that brought Windows development to the masses, while also being maligned and looked down-upon by “real” developers. Personally, I don’t think there’s a bit of doubt about the former, and I think the latter is a sad commentary on the people who trash-talk VB.
Even though I’ve largely converted to C# development myself, I’ve got a pretty huge soft spot for VB, because (yes, it’s true) it’s how I got my start in Windows development. I wasn’t alone; huge numbers of developers flocked to Microsoft development technologies because of VB. Try as they might, Microsoft hasn’t been able to catch lightning in a jar a second time. They need to — pretty badly — if they’re to regain dominance in a web world.
Every time I learn an easier way to do something, I’m glad I learned it, but I feel like an idiot for not finding it sooner. Here’s a perfect example. Here’s the hard way to check for an expected exception in a VSTS unit test:
/// Test for an expected exception - the hard way
public void TestForExceptionWorse()
bool caughtErr = false;
caughtErr = true;
Assert.IsTrue(caughtErr, "Expected SpecificExceptionToCatch, but none was thrown.");
It turns out there’s an easier way to do this:
/// Test for an expected exception - the easy way
"Expected SpecificExceptionToCatch, but none was thrown.")]
public void TestForExceptionBetter()