运行时处理用户输入：使用Try-Catch是否为最佳实践？

嘿，我来帮你捋清楚这个问题！你现在用try-catch块来掩盖输入文本长度不足时的参数越界异常，虽然程序能正常运行，但这确实不是最佳实践——异常处理的设计初衷是应对意外错误，而不是用来控制正常的用户输入流程。咱们来看看更优雅、更合理的解决方案：

核心优化思路：先检查文本长度，再执行判断逻辑 #

用户输入是动态的，每次TextChanged触发时，文本框里的内容可能还没达到你需要的8+字符长度。所以在执行那些需要截取特定位置字符的判断前，先检查当前文本的长度是否满足要求，不够就直接跳过后续逻辑，从根源上避免异常。

修改后的代码示例 #

private void txtBoxEingabe_TextChanged(object sender, EventArgs e)
{
    axAcroPDF1.LoadFile("DONTEXISTS.pdf");
    radioButton1.Visible = false;
    radioButton2.Visible = false;
    string text = txtBoxEingabe.Text;

    // 先检查文本长度是否满足所有截取操作的要求：需要至少9个字符（索引0-8）
    if (text.Length >= 9)
    {
        // 现在可以安全地执行所有截取和判断了
        if (text.Substring(0, 3) == "SEH" 
            && text.Substring(3, 1) == "M" 
            && int.TryParse(text.Substring(4, 4), out int num) && num <= 2999 
            && (text.Substring(8, 1) == "H" || text.Substring(8, 1) == "R"))
        {
            radioButton1.Visible = true;
            radioButton2.Visible = true;
            radioButton1.Text = "1. Document";
            radioButton2.Text = "2. Document";
            // 注意：事件绑定不要放在TextChanged里！会重复绑定导致多次触发
            // 把下面两行移到Form的构造函数或者Form_Load事件中
            // this.radioButton1.CheckedChanged += RadioBtnChangedDC1;
            // this.radioButton2.CheckedChanged += RadioBtnChangedDC1;
        }
    }
}

private void RadioBtnChangedDC1(object sender, EventArgs e)
{
    if (radioButton1.Checked)
    {
        axAcroPDF1.LoadFile(@"C:\Doc1.pdf");
        axAcroPDF1.gotoFirstPage();
        int Screensize = 100;
        axAcroPDF1.setZoom(Screensize);
        axAcroPDF1.setShowScrollbars(true);
        axAcroPDF1.setShowToolbar(false);
    }
    else if (radioButton2.Checked)
    {
        axAcroPDF1.LoadFile(@"C:\Doc2.pdf");
        axAcroPDF1.gotoFirstPage();
        int Screensize = 100;
        axAcroPDF1.setZoom(Screensize);
        axAcroPDF1.setShowScrollbars(true);
        axAcroPDF1.setShowToolbar(false);
    }
}

额外优化点 #

• 用int.TryParse替代Convert.ToInt32：如果文本截取的部分不是数字，Convert.ToInt32会抛出异常，而int.TryParse会安全返回false，避免额外的异常风险。
• 避免重复绑定事件：原来的代码每次TextChanged触发都给单选按钮绑定CheckedChanged事件，会导致同一个事件被绑定多次，触发时执行多次逻辑。应该把事件绑定移到窗体的构造函数或者Form_Load事件中，只绑定一次。
• 路径字符串用@转义：比如@"C:\Doc1.pdf"，避免转义字符的语法问题。

为什么不推荐用try-catch？ #

1. 性能开销大：异常处理的性能消耗远高于普通条件判断，频繁触发TextChanged时会拖慢程序响应速度。
2. 隐藏潜在问题：空的catch块会掩盖其他意外异常（比如格式转换错误、文件路径错误等），不利于后续调试和维护。
3. 逻辑不直观：显式的长度检查比try-catch块更易懂，其他开发者看代码时能快速理解输入校验的逻辑。

内容的提问来源于stack exchange，提问作者Rafael