Monday, December 10, 2007

Another nice shortcut in .NET 2.0

OK, who can tell me what's wrong with the following VB.NET code?

Public Sub MyMethod(ByVal inputString As String)

Try

' Validate input
If inputString Is Nothing Or inputString.Trim.Length = 0 Then
' However you want to handle the error...
End If

' More functionality here

Catch
' Error-handling code

End Try

End Sub

[Jeopardy theme plays...]

Basically, the line where we check the "nothing-ness" or "blank-ness" of inputString will always error-out if the string actually is nothing. This is because And and Or in VB.NET are not short-circuited. Both sides of the operator always run, and Nothing.Trim.Length will cause an invalid object exception. Technically, it's not worth checking the right side of an And if the left is false nor the right side of an Or if the left is true, but VB.NET does it anyways by default. If one argument in an And statement is false, the whole statement is false. If one argument in an Or statement is true, the whole statement is true (not counting exclusive or). To achieve this level of functionality, an earlier version of VB.NET introduced the AndAlso and OrElse operators. Basically, they will stop evaluating if the outcome can be determined after looking at just the left side of the statement. So, our code above would become:

If inputString Is Nothing OrElse inputString.Trim.Length = 0 Then

Now, with VB.NET 2.0, we have a new operator that achieves the same code as above. So, it can be further reduced to:

If String.IsNullOrEmpty(inputString) Then

Microsoft must have realized that people were having issues because they may have been used to languages where And and Or are short-circuited by default. It's a nice shortcut if you can remember to use it!

Sunday, December 2, 2007

Visual Studio 2005 Debugging Bug

I suppose one might say that the title of this entry is somewhat ironic. Regardless, I'm not bashing Microsoft. Indeed, I am actually very fond of Visual Studio and all the features it provides. The problem I recently encountered, though, was a bit of a nuisance. I've gotten in the habit of running the websites I'm developing with Ctrl-F5 to start without debugging when I'm fairly certain there won't be any issues. Internet Explorer opens a little faster and you can continue to edit in Visual Studio even if the browser window is still open. However, I occasionally encounter a flaw in my code during this debugger-less browsing and decide to start the site with debugging to get more details. Here-in lies the crux of the problem. If you forget to close the original browser window that was started with you were running without debugging, the new session with debugging will actually time-out with an error message that your action failed. Even if you then go back and close the original browser window, all subsequent attempts to run with debugging will fail in the same manner. Performing an IIS reset does not solve the issue. The only thing that seems to work is to close and re-open Visual Studio. At one point last week, I actually had to re-boot to get things working again. So, remember to always close any browser window previously spawned by Visual Studio prior to hitting F5 to launch the site you are developing with debugging enabled.