我目前正在设计一个处理不同类型文件的系统。我定义了如下接口(interface)
public interface IFileProcessor
{
bool ProcessFile(string fileContents)
}
旨在创建一些具体的实现来处理不同的文件类型。 Controller 类将负责:
- 查看文件夹中是否有新添加的文件
- 读取文件内容
- 获取这些 IFileProcessor 具体实现的集合
- 在每个组件上逐一调用 ProcessFile(),传递文件内容
- 如果组件无法处理文件则返回 false,否则它将处理内容并返回 true
- 如果没有 IFileProcessor 实现可以处理文件, Controller 会将其移动到“UnProcessed”文件夹
- 如果一个组件成功地处理了文件,它将被移动到“已处理”文件夹
- 如果组件抛出异常,则将其移至“失败”文件夹
我正在创建 IFileProcessor 的实现,它将首先检查它是否可以根据类型(即 csv)处理文件,然后执行一些顶级验证(即检查文件头)。如果这些检查中的任何一个失败,将向 Controller 抛出异常,因为整个文件被视为无效。
然而,一旦顶级验证成功,组件将处理文件中的每一行。从这一点开始,单个行处理失败(即验证)是可以接受的,其余过程继续进行。
这就是问题所在,我想知道是否最好记录已发生的验证错误然后在流程结束时抛出异常,或者更改 ProcessFile() 签名以返回一个枚举(其中之一已处理、未处理、ProcessedWithErrors)?
从我读到的内容来看,异常似乎是状态代码的首选途径,但是在这种进程可以继续的特定情况下,在最后使用人为异常来声明进程未完成 100% 似乎是错误的.
我真的很想知道人们对此的看法。
最佳答案
一个建议:
让它返回一个调用者可以检查的对象,而不是返回一个 bool 值或一个枚举。也许称它为 FileProcessorResult。在该对象中,您可以存储各种信息,如总体成功或失败、验证状态、处理状态等。
在严重失败的情况下,我会返回异常,以便调用者可以采取正确的操作。您可以派生一个异常类,以便 try catch 是干净的。
例子:
try
{
FileProcessorResult fpr = ProcessFile(Contents);
//Do something with fpr
}
catch (FileProcessorException fpe)
{
//Something unexpected occured during file processing, handle it
}
我可能没有绝对正确的答案,所以请将此作为建议。
关于c# - 可以处理错误的组件的异常或返回状态,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7732136/