在逻辑不可能场景抛出异常：最佳实践还是冗余代码？

这得看具体场景，但多数情况下，这种做法属于防御性编程，是值得提倡的良好实践，而非冗余代码。

先看你给出的示例代码：

def __init__(self, type, list_of_variables):
        if type == "var":
            rand_index_var = random.randint(0,len(list_of_variables)) # 该随机数基于list_of_variables生成
            if len(list_of_variables) >= rand_index_var: # 此条件理论上不会不成立，至少非人为错误不会导致其触发
                self.symbol = list_of_variables[rand_index_var]
            else:
                raise Exception(f"list index out of range {rand_index_var}")

这里得先纠正一个小误区：random.randint(a, b)会返回包含a和b的整数，所以当list_of_variables的长度是n时，rand_index_var可能等于n，而列表的最大合法索引是n-1——也就是说这个“理论上不会不成立”的条件，其实会触发，此时这段异常判断完全是必要的，能直接抛出明确的错误，而不是让程序因索引越界崩溃。

如果假设真的存在逻辑上绝对不可能触发的条件（比如你把代码改成random.randint(0, len(list_of_variables)-1)，此时rand_index_var的最大值是len(list_of_variables)-1，len(...) >= rand_index_var必然成立），这时候保留异常判断依然有意义：

• 捕捉隐性漏洞：后续代码迭代时，可能有人修改randint的参数、或者修改list_of_variables的生成逻辑，导致原本成立的逻辑被打破。异常能在第一时间抛出明确错误，帮你快速定位问题。
• 应对极端异常场景：你提到的操作系统故障、硬件错误等极端情况确实存在——比如内存 corruption 导致len(list_of_variables)返回错误值，或者多线程环境下列表被意外修改。这种时候，异常能阻止程序静默执行错误逻辑，避免更严重的后果。
• 代码自文档化：这段判断和异常相当于给维护者留下注释：“这里的逻辑应该是XXX，如果触发这个异常，说明出现了超出预期的严重问题”。

当然，也存在极少数可以视为冗余的场景：比如在性能极其敏感的高频调用路径中，额外的判断会带来可感知的性能损耗，且逻辑经过严格数学推导绝对不可能出错。但这种场景非常少见，多数时候，保留这类异常判断的收益远大于成本。

你想保留当前代码版本的思路是合理的——用极低的代码成本，换取极端场景下的错误可追溯性，完全值得。

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