【问题标题】:Best Practices for handling Error Strings处理错误字符串的最佳实践
【发布时间】:2009-08-14 12:51:36
【问题描述】:

在我的 vb.net 应用程序中,如果我有一组已知的错误字符串,即

  • 因为我不知道所以失败了
  • 失败,因为我知道但我找不到它
  • 由于其他原因失败

我得到一个响应,我想确保其中没有错误字符串

If returnedString.equals("Failed because I don't know about it") then 
    'do something'
End if

人们如何最好地建议我避免对错误字符串进行硬编码。

理想情况下,可以在此处使用枚举,但无法比较返回的错误字符串。 (如果我错了,请纠正我!)

这些最好作为字符串保存在资源文件中,还是最好为每个错误字符串提供一个带有共享公共属性的 ErrorClass 并检查

If returnedErrorString.equals(ErrorClass.UnknownString) then 
        'do something'
End if

或者还有其他(更好的?)方法可以做到这一点吗?

编辑:我认为在这种情况下异常建议不是最好的,因为返回的错误代码不一定会导致应用程序失败,但可能会改变程序流程,如向用户显示的内容,我必须查看在错误字符串中,因为这些字符串由我控制并从外部应用程序返回

【问题讨论】:

  • 但如果它们来自外部应用程序,那么您对字符串无能为力!已经提出的任何建议都不起作用!
  • 但我必须有一种方法来确定外部应用程序返回了什么......因为它可能是错误或成功代码。所以我需要能够说返回的值是否等于这个错误或这个错误或一个成功代码(如果这有意义吗?)
  • 是的,这是有道理的。听起来外部应用程序相当老旧,或者不是 .NET 应用程序,因为这种错误/成功代码风格不再使用(至少在 .NET 应用程序中)。我也更新了我的答案 (stackoverflow.com/questions/1277682/…) 以适应您问题的更新。
  • 外部应用程序没有关于如何判断它是否是错误以及什么样的建议?他们有错误信息列表吗?他们可能在资源或其他东西中有他们的消息吗?我担心你今天制作常量或资源,明天外部应用程序更改标点符号!

标签: .net vb.net error-handling


【解决方案1】:

我会说首选方法不是使用错误字符串,而是为不同的,嗯,异常创建自定义异常类:

UnknownException
NotFoundException
OtherReasonException

那么您就有了一种类型安全的方法来确定错误原因,这也与翻译文本和类似问题的问题脱节。

MSDN 在how to create user-defined exceptions 上有一篇文章。

【讨论】:

  • 我支持异常路由,但这只会将描述的问题转移到错误字符串(来自外部应用程序)映射到异常的地方。我认为 vb 等效的 switch 应该可以解决问题。
【解决方案2】:

在我 30 多年的经验中,查看错误字符串以编程方式确定出了什么问题一直是错误的。标点符号变了怎么办?

我同意使用自定义异常的建议,但我只会创建一个自定义异常。我会定义一个枚举的原因:

public enum ExceptionReason {
    Unknown,
    NotFound
}

我会给你的自定义异常这个枚举类型的属性。

对于“其他”的情况,只需抛出现有的Exception 类。事实上,你会喜欢通过异常发现“其他”,在这种情况下,不要捕捉它 - 让它过去吧。

【讨论】:

  • 您应该在枚举中添加一个项目 - “其他”,以使其足以满足 OP 的目的。 +1阅读我的想法! :P
  • 为什么要给异常一个属性而不是自定义异常?
  • @boris: 1) 检查属性值比检查 catch 子句中异常实例的类型更有效; 2)正确实现异常需要相当多的样板代码,用于序列化,实现所有重载等。最好只做一次。
  • @Cerebrus:我建议不要在“其他”情况下使用自定义异常,而只是 System.Exception
  • @Bryan:有多干净?另外,每个异常类需要多少行代码?
【解决方案3】:

使用字符串来指示错误条件,无论它们是否是实际的例外情况,其本身都容易出错。如果您必须这样做,那么在进行这样的字符串比较时需要注意的一件事是它们区分大小写,因此您可能应该使用String.Compare(string, string, StringComparison) 而不是相等。

由于错误字符串来自外部应用程序(我认为这意味着您无法控制它们),最好的选择是将对该外部应用程序的调用包装起来,这样您就可以封装“错误处理"(即字符串求值)并在适当时抛出异常或返回某种错误“代码”(通过枚举处理)。

如果错误条件本身并不代表实际的异常情况,您很可能会使用它们来控制程序流程,在这种情况下您不想抛出异常。请记住,虽然抛出异常并不昂贵,但捕获一个异常。否则,您应该考虑引发异常,最好使用符合错误描述的现有 .NET 异常。如果找不到,则应创建自定义异常。

就资源字符串本身而言,最好将实际文本存储在资源文件中。这使您能够(稍后)能够更轻松地本地化文本,允许您使用单个存储位置,并提供强类型类来访问字符串。

【讨论】:

    【解决方案4】:

    您可以使用资源来存储您的字符串。

    您可以根据自己的分类命名这些资源文件:

    IOErrors.resx
    
    DBErrors.resx
    
    FormatErrors.resx
    

    等等

    然后你在你的项目中简单优雅地引用它们,例如:

    Resources.FormatErrors.WrongDateFormat
    

    【讨论】:

      【解决方案5】:

      我会改为使用错误代码的枚举列表。依赖字符串比较很容易出现陷阱(例如区分大小写、多语言问题等)。

      我正要发布一个示例 enum(几乎与 @John 发布的相同),但他的示例似乎已经足够了。

      【讨论】:

        【解决方案6】:

        我同意上述 cmets - 但是,如果您必须进行比较,则为字符串创建一个命名常量,并与该常量进行比较。这样,如果您更改错误字符串,则代码不会中断。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2018-09-12
          • 2017-11-26
          • 2016-06-06
          • 1970-01-01
          • 1970-01-01
          • 2019-10-28
          相关资源
          最近更新 更多