前言

编程的世界充满了挑战和乐趣，异常就是我们绕不过去的大石头。

有时候，我们需要主动引发一些异常；

有时候，我们又需要主动捕捉一些异常；

有时候，我们还需要学会消灭一些异常；

……

所以，我们需要一套异常使用原则来帮助我们稳住船舶，不让意外搅乱了我们的编程节奏！

今天，我们就来聊聊六个关于异常使用的黄金法则，帮助你在这个充满挑战的领域中游刃有余。

六大原则

1. 不要对在可控范围内的输入和输出引发异常

这个原则的意思是，

在编写代码时，如果某些输入或输出是你可以预见并且可以控制的，就不要引发异常。

想象一下，你正在编写一个计算器应用程序。

用户输入了两个数字，你准备进行除法运算。如果用户输入的除数是零，你会怎么做？抛出异常吗？

不！在这种情况下，你可以简单地返回一个错误消息，或者提示用户重新输入。

因为，用户输入零是可控的，没必要大惊小怪。

public int Divide(int a, int b)
{
    if (b == 0) 
    {
        Console.WriteLine("分母不能为零，请检查输入！");
        return 0; // 或者其他合理的默认值
    }
    return a / b;
}

2. 正常的业务流程尽可能不要使用异常来处理

假设你正在编写一个电商网站的订单处理系统。

如果用户尝试购买一个已经售罄的商品，你会抛出异常吗？

当然不！

你可以简单地返回一个“商品已售罄”的消息，或者将用户引导到其他商品页面，因为这是一个正常的业务逻辑。

异常是用来处理意外情况的，而不是用来处理正常的业务流程。

// 错误示范
try
{
    var result = GetProductById(productId);
} 
catch (NullReferenceException ex) 
{
    // 处理商品不存在的情况
}

// 更好的做法
var product = GetProductById(productId);
if (product == null)
{
    Console.WriteLine("当前商品已售罄");

    // 引导到其他商品页面
}

3. 不要总是尝试去捕获异常，允许异常往上传播

假设你正在编写一个底层的文件处理程序。

如果文件读取失败，你需要立即捕获异常并处理吗？不一定！

有时候，让异常向上传播到更高层的代码中处理可能更合适。

这样，你可以集中处理异常，而不是在每个方法中都进行捕获。

public void FileHandler()
{
    try 
    {
        ReadFile();
    }
    catch (Exception ex) 
    {
        throw; // 让异常往上传播
    }
}

4. 如果运行代码后，会造成内存泄漏、资源不可用，或者应用程序状态不可恢复，则引发异常

假设你正在编写一个很占内存的操作。

如果操作可以导致内存占用过高，你会怎么做？抛出异常！因为如果内存占用过高，应用程序的状态将不可恢复。

在这种情况下，抛出异常是必要的。

List<byte[]> memoryLeakList = new List<byte[]>();
long memoryThreshold = 1024 * 1024 * 100; 

while (true)
{
    byte[] buffer = newbyte[1024 * 1024];
    memoryLeakList.Add(buffer);

    if (GC.GetTotalMemory(false) > memoryThreshold)
    {
        thrownew OutOfMemoryException("内存使用超过阈值，可能导致内存泄漏或应用程序状态不可恢复。");
    }

    Thread.Sleep(100);
}

5. 在捕获异常的时候，如果需要包装一些更有用的信息，则引发异常

这类异常的引发在 UI 层特别有用。

系统引用的异常所带的信息往往更倾向于技术性的描述；

而在 UI 层，面对异常的很可能是最终普通用户，所以如果需要将异常的信息呈现给最终用户，更好的做法明显是先包装异常，然后引发一个包含友好信息的新异常。

try 
{
    MyOperation();
}
catch (FileNotFoundException ex)
{
    throw new FileNotFoundException($"无法找到指定的文件: {ex.FileName}", ex);
}

6. 如果底层异常在高层操作的上下文中没有意义，那么在捕获这些异常时，引发新的有意义的异常

假设你正在调用 Windows API 或第三方 API 提供的接口时，如果对方的异常报告机制使用的是错误代码，很不好理解，这时你会怎么办？

最好的方法是重新引发该接口提供的错误，创建一个新的更有意义的异常，因为你需要让团队更好地理解这些错误。

int errorCode = CallApi();

if (errorCode == 6) 
{
    throw new FileNotFoundException($"文件路径无效. [{path}]");
}

总结

在编程的世界里，异常处理是一门艺术。

本文我们一起探讨了六个关于异常使用的黄金法则。

好的异常使用原则就像是为我们的代码设置了安全带。

记住，异常不是敌人，而是提示我们需要关注的地方。

阅读原文：原文链接