使用异常处理业务逻辑是否是好的实践？示例代码存在问题吗？

异常的设计初衷是处理程序运行过程中不符合预期的错误情况，而非用来做正常业务流程的分支控制，你给出的代码是否存在问题完全取决于实际业务场景。

不同场景的合理性判断 #

• 场景1：路径不存在属于可预见的正常业务分支
  比如该功能允许用户输入任意路径查询对应目录下的图片，路径不存在就是用户输入的正常情况之一，这种场景下你的代码属于不良实践：

  1. 有额外性能损耗：异常的栈回溯生成、捕获处理的开销远高于提前调用文件存在性检查的成本，高并发场景下差异会非常明显。
  2. 可维护性差：正常的业务分支逻辑被藏在catch块里，后续维护人员很难快速梳理清楚所有业务分支，不符合常规的代码编写习惯。
     这种场景建议优先做前置校验：

  if(!Directory.Exists(path)){
      return [];
  }
  images = this.getFinderFiles(path);
  

• 场景2：路径不存在属于违反约定的异常情况
  比如上层调用方已经保证了传入的path必然是存在的合法路径，路径不存在属于程序运行过程中的意外错误（比如目录被其他进程意外删除），这种场景下你的代码是完全合理的：

  这种情况符合异常的设计初衷，捕获异常后返回空数组作为降级策略，避免程序崩溃是常规操作。

额外注意点 #

你当前的代码只捕获了DirectoryNotFoundException，如果getFinderFiles方法还会抛出其他IO相关异常（比如权限不足的UnauthorizedAccessException、路径格式非法的ArgumentException），这些异常会直接向上抛出。如果你希望所有读取文件失败的场景都统一返回空数组，需要补充对应的捕获分支，或者捕获更通用的异常后做类型判断，避免非预期的异常泄漏。

内容的提问来源于stack exchange，提问作者Jakub Mróz