别把 VB.NET 当成只会写 WinForms 的“老古董”

最近在复盘一些旧项目的逻辑，发现很多开发者（包括早期的我）在处理 VB.NET 时，习惯性地把这种“宽容”的语言当成了避风港，结果却掉进了工程效率的陷阱。从 QA 的角度来看，最怕的就是那种“看起来运行正常，实则数据已经腐烂”的代码。

最典型的坑就是滥用 On Error Resume Next。这玩意儿就像是在代码里埋地雷，它不解决问题，只是把尸体藏起来。一旦数据库返回了异常字符串，程序会带着错误的默认值一路向下传递，等到最后层级报错时，你根本无法溯源。

' 这种“掩耳盗铃”的写法在生产环境是灾难
Public Sub ProcessData()
    On Error Resume Next
    Dim userData As String = FetchFromDatabase()
    Dim score As Integer = Convert.ToInt32(userData) ' 如果是 null，错误被静默忽略了
    DisplayScore(score)
End Sub
' 应该采用这种 Fail-fast（快速失败）的工程化思路
Public Sub ProcessData()
    Try
        Dim userData As String = FetchFromDatabase()
        Dim score As Integer = 0
        If Integer.TryParse(userData, score) Then
            DisplayScore(score)
        Else
            Logger.LogWarning("Invalid user data format.")
        End If
    Catch ex As SqlException
        Logger.LogError("Database connection failed", ex)
        ShowFriendlyErrorMessage()
    End Try
End Sub

另外，我发现很多老项目的工程设置里 Option Strict 是关闭的。这在类型安全要求极高的环境下简直是性能杀手。关闭它意味着编译器会进行大量的隐式转换（Implicit Conversion），这不仅增加了运行时负担，更会导致 InvalidCastException 这种本该在编译阶段就被拦截的错误直接冲进生产环境。

一定要在文件头部强制开启严格模式：

Option Strict On
Option Explicit On
Dim myText As String = "123"
' 编译器会直接拦截这种类型不匹配，而不是等运行到这一行才报错
' Dim myNumber As Integer = myText 
Dim myNumber As Integer = Convert.ToInt32(myText)

最后还要提一个逻辑运算符的细节，这跟 C# 的 && 逻辑完全不同。在 VB 中，如果你写 And 或 Or，它是不会进行短路运算（Short-circuiting）的。这在处理空引用检查时极其危险。

' 极其危险：即便 user 是 Nothing，也会尝试读取 .IsAdmin，导致 NullReferenceException
If user IsNot Nothing And user.IsAdmin Then
    GrantAccess()
End If
' 正确做法：必须使用 AndAlso 或 OrElse
If user IsNot Nothing AndAlso user.IsAdmin Then
    GrantAccess()
End If

从工程效率角度看，严格的类型检查和正确的逻辑运算符能帮你节省至少 30% 的调试时间。