异常设计:从文件读取数据的自定义异常?

我会说 快速而响亮地失败 . 所以在出现不一致的时候抛出一个异常(除非您想保留文件中的所有错误并将其显示给用户…在这种情况下,您需要一个基于参数的收集设计与一个基于异常的收集设计)。

• 将自定义异常类命名为“意向揭示”。因此,nametoolongexception比invalidnameexception更好
• 此外,异常应该对客户机修复问题有帮助。(啊,我需要缩短文件中的名称,而不是深入挖掘异常/代码来了解名称无效的原因。)缩短客户机的发现和解决周期。

如果数据不可用,那么最好在读取记录时抛出异常。例如,如果您知道年龄字段中的字符数据只有在用户在应用程序外部处理文件时才可能出现。如果您试图序列化一个对象,弄乱了序列化的数据,然后试图反序列化它,就会发生这种情况。

如果要在应用程序外部操作数据,或者可以恢复某些记录或其他记录,那么最好实现某种复合“错误”集合。您不必抛出异常。您可以创建新的异常实例,并将它们放在集合中。

换句话说,只有当您希望中断当前操作,并且不希望返回部分结果时,才应该抛出异常。

这取决于你的逻辑是如何建立的。如果您的文件读取逻辑是通用的(不是C通用的,从某种意义上说是非特定的通用的),那么最好将异常放在稍微高一点的位置。

例如,如果事情是这样设置的:

// just an example
FileContents ReadFile(string path)
{
   // Don't necessarily throw exceptions related to data validity
}

SomeObject FromFile(string path)
{
   FileContents contents = ReadFile(path);
   // Do throw exceptions related to data validity

   // construct your object
}

所有这些都归结为在哪里进行验证是合理的。作为一般规则,您应该只在异常情况下抛出异常(您无法在该特定级别恢复的情况)。调用堆栈中较高的某个方法可能知道在这种情况下该怎么做。

此外,如果您必须抛出许多不同类型的异常,作为对方法调用方(间接或直接、您或其他开发人员)的礼貌,最好使异常具有公共的基本异常(而不是 System.Exception ,所以可以用很少的 catch 必要时的声明。

继承层次结构的一个示例可能是:

• 系统异常
  • 数据加载异常
    • 命名异常
      • 名称工具例外
      • 无效的名称例外
    • 年龄异常
    • …

这样,如果调用者只想知道方法是否成功,那么他们只需要捕获 DataLoadException 而不是捕获每种类型的可丢弃异常。如果打电话的人想知道到底出了什么问题,他们也可以这样做。

看起来你在做一些事情:

1. 读取外部数据源(文件)
2. 从读取的数据构造对象。
3. 将对象传递到应用程序的另一部分(以执行进一步的处理)。

我将验证限制在以下情况:

1. 如果无法读取文件,请在此处引发(没有文件,文件格式错误)。
2. 如果因为这里的数据引发而无法构造对象(“年龄”因为非数字字符而无法解析)。
3. 验证 业务逻辑 (名称太长或太小,重量太大或太小)in 业务层 .

它最适合批处理,我想说,创建一个验证和错误数据类。数据类将具有linenumber(csv linenumber)、message和if you think any properties suitale。

读取文件并将整个集合传递到验证类中,以验证和获取ErrorData类集合中的错误。

处理正确的数据并记录或抛出错误。在这里,您既要处理写数据,也要通知客户机(调用对象)存在错误。

有人可以打开日志/或错误消息来更正数据。