【问题标题】:Which exception should be thrown for an invalid file name?对于无效的文件名应该抛出哪个异常?
【发布时间】:2010-11-28 03:20:51
【问题描述】:

我有一个接受文件名作为参数的方法,所有文件名都应以“.csv”结尾。如果传递了不以 .csv 结尾的文件名,我应该抛出哪个异常?

或者我应该采取不同的方法吗?

【问题讨论】:

  • 如果用户有一个逗号分隔值格式的*.txt 文件会发生什么?对于任意应用程序,这种情况下的预期行为是允许通过FileDialog 中的“所有文件”过滤器或带扩展名的完整文件名输入显式选择文件。

标签: .net exception-handling


【解决方案1】:

ArgumentOutOfRangeException - 您所描述的内容符合超出范围的异常:

执行时抛出的异常 参数的值在 定义的允许值范围 通过调用的方法。

ArgumentException 用于验证路径字符串中的字符,而不是文件类型。

路径参数是零长度 字符串,仅包含空格,或 包含一个或多个无效 字符。

恕我直言,路径验证失败图表如下所示:

如果这对您来说描述性不够,请创建您自己的异常类:

public class InvalidFileTypeException : System.IO.IOException
{
    public InvalidFileTypeException(string path, string acceptedTypeMask) 
    {
        this.Message = string.Format(
            "File type '{0}' does not fall within the expected range: '{1}'", 
            path, 
            acceptedTypeMask);
    }
}

...

throw new InvalidFileTypeException("foo.txt", "*.csv");

【讨论】:

  • +1,同意 - 正如 ArgumentException 的文档所述,“ArgumentException 的主要派生类是 ArgumentNullExceptionArgumentOutOfRangeException。应该使用这些派生类而不是 @987654336 @,除非派生类都不可接受。"
【解决方案2】:

ArgumentException 符合 IMO 的要求。

【讨论】:

    【解决方案3】:

    我可能会使用ArgumentException,因为它是“当提供给方法的参数之一无效时引发的异常”

    【讨论】:

      【解决方案4】:

      查看框架中现有 IO 方法的文档。它描述了一个方法产生的异常。例如,检查StreamWriter.StreamWriter(String, Boolean, Encoding, Int32) Constructor http://msdn.microsoft.com/en-us/library/0wf7ab94(VS.85).aspx。为了保持一致,我建议您使用的异常是 IOException。然后,您可以添加描述详细信息的自定义消息。

      IOException - 路径包含不正确或无效的文件名、目录名或卷标语法语法。

      在你的情况下,文件扩展名不正确,所以告诉用户,如Throw New IOException("Invalid file extension.")

      我会按照文档中的说明保留 ArgumentExceptionpath 是一个空字符串 ("")。"

      请参阅Choosing the Right Type of Exception to Throwhttp://msdn.microsoft.com/en-us/library/ms229021.aspx

      【讨论】:

      • 这很好。我对框架如何处理这个问题不太满意,但如果你想与 Stream 类保持一致,这样做可能是个好主意(假设有问题的方法实际上与 IO 相关)
      • 同意,但是在我习惯了 IO 异常之后,我并不太介意。将 ArgumentException 保留为已定义的一个好处是可以在文件名真正为“”时轻松调试。
      • 不,不正确(但有效)的扩展不是 IOExcpetion。在这个级别,这是一个被破坏的约束。
      • 好点。然而......我更想指出开发人员查看现有文档以获得指导。
      【解决方案5】:

      System.ArgumentException 看起来很合适,可以直接使用,也可以作为异常的基类。

      【讨论】:

        【解决方案6】:

        创建自己的InvalidFilenameException 怎么样?例如:

        public class InvalidFilenameException : Exception
        {
            public string Filename { get; private set; }
        
            public InvalidFilenameException(string message, string invalidFilename)
                :base(message)
            {
                Filename = invalidFilename;
            }
        }
        

        【讨论】:

        • 您编写的代码越多,出现错误的可能性就越大,花费的时间越多,必须做出的决定就越多。除非特别需要自定义异常,否则最好避免使用它们。
        • 嗯,当然。但是,如果我发现创建自己的异常更清楚,如果你真的找不到真正适合的人。就像建议的 IOException 一样。真的是 IOException 吗?我可能会使用此处其他人建议的 ArgumentException。但只是想我可以带一个替代品。
        • 是的。 Henk Holterman 提出了一个很好的观点。提出建议有点困难,因为问题很模糊。这就是为什么我试图让开发人员查看现有文档以获取指导。
        • 这是一个非常好的主意。问题是当你忘记你有替代存在的东西时。至少我经常发现自己试图在框架中使用一些不适合我需要的东西,并试图将它扭曲成我需要的东西。但后来我意识到我在做什么,并记住,嘿,我为什么不从某些东西或从头开始继承,并制作我自己真正想要的东西,而不是我想要的东西。
        猜你喜欢
        • 1970-01-01
        • 2015-05-12
        • 1970-01-01
        • 2013-06-05
        • 2016-07-29
        • 1970-01-01
        • 2011-04-27
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多