面试题：Rust中panic!宏与Result类型的抉择及应用

优先选择panic!宏的场景

程序处于开发阶段：在开发和调试过程中，对于不应该发生的情况，例如某个函数的前置条件被破坏。假设你有一个函数，预期接收一个非零整数，但如果接收到零，这在逻辑上是不应该出现的，此时使用panic!宏方便定位问题。

fn divide(a: i32, b: i32) -> i32 {
    if b == 0 {
        panic!("Division by zero is not allowed");
    }
    a / b
}

不可恢复的错误：当错误发生后，程序无法继续以有意义的方式运行时，如无法连接到关键的外部服务，且没有备用机制。比如连接数据库失败，而该数据库是程序正常运行的基础，没有数据库连接程序无法提供任何有效功能，此时panic!可以快速终止程序。

优先选择Result类型的场景

可恢复的错误：在日常的业务逻辑中，一些错误是可以被预料到并且程序可以继续运行的。例如读取文件可能因为文件不存在而失败，但程序可以提示用户或者尝试其他操作。

use std::fs::File;
use std::io::Read;

fn read_file_content(file_path: &str) -> Result<String, std::io::Error> {
    let mut file = File::open(file_path)?;
    let mut content = String::new();
    file.read_to_string(&mut content)?;
    Ok(content)
}

错误处理需要向调用者传递信息：当调用者需要根据不同的错误类型做出不同的反应时，Result类型可以携带具体的错误信息。例如网络请求失败，调用者可能需要知道是超时错误、连接错误还是其他错误，以便采取不同的重试策略。

根据实际业务需求的合理抉择

考虑错误对业务的影响：如果错误只是一个小问题，不影响整体业务的核心流程，使用Result类型更合适，这样程序可以更优雅地处理错误并继续运行。但如果错误会导致业务无法进行下去，如缺少关键配置文件，panic!宏终止程序可以避免程序进入未知状态。
调用者的期望：如果调用者期望能够处理错误并做出相应调整，Result类型是首选。如果调用者更希望程序在遇到意外情况时直接终止，避免产生错误的中间状态，panic!宏更符合需求。

对代码健壮性和可维护性的不同影响

panic!宏：
- 健壮性：在遇到不可恢复错误时，panic!宏可以防止程序在错误状态下继续运行，从而避免产生难以调试的错误结果，从这个角度增强了健壮性。但如果在生产环境中频繁panic，会导致程序不稳定。
- 可维护性：在开发阶段，panic!宏使得错误一目了然，方便定位问题，提高开发效率。但在生产环境中，过多panic可能导致程序崩溃，增加维护成本。同时，panic!宏使错误处理逻辑不清晰，因为没有明确的错误返回路径，不利于代码的长期维护。
Result类型：
- 健壮性：通过显式处理错误，程序可以在各种错误情况下保持运行，提高了健壮性。调用者可以根据不同的错误类型进行相应处理，避免程序意外终止。
- 可维护性：Result类型使错误处理逻辑清晰，调用者可以清楚地看到可能出现的错误类型以及如何处理。代码结构更清晰，有利于长期维护和扩展。但过多的Result类型处理可能使代码变得冗长，需要合理使用?操作符等方式简化代码。

星途面试题库

面试题：Rust中panic!宏与Result类型的抉择及应用

知识考点

面试题答案

优先选择panic!宏的场景

优先选择Result类型的场景

根据实际业务需求的合理抉择

对代码健壮性和可维护性的不同影响