2010-12-11 44 views
4

所以,我一直在努力工作的新项目,今天有一位同事提出的想法,我的例外,甚至返回的错误信息应该完全本地化。我想也许这是一个好主意,但他说,我应该只错误返回错误代码。我个人不喜欢的错误代码的想法很多,因为它往往使其他程序员或者要使用错误代码或不使用错误代码

  1. 为了重复错误代码,他们不适合,因为他们不希望添加另一个
  2. 他们倾向于使用错误的错误代码,因为可以定义这么多。

所以我的问题是其他人做什么来处理这种情况?我接受各种建议,包括那些认为错误代码是可行的方法。

回答

3

根据您的编码语言,可能存在文化差异?

在Java例如,数值错误代码不常使用...


有关例外,我相信这只是一个技术工具。 重要的是你的消息是针对用户还是开发者。 对于用户来说,本地化消息很重要,如果出现几种语言,或者能够在不重新编译的情况下更改消息(在客户端之间自定义,以适应不断变化的用户需求)。


在我的项目,我们的文化是使用(JAVA)枚举处理固定值的所有集合。 错误没有什么不同。 枚举错误可以提供:

  • 强类型(你不能通过别的东西是期待一个错误代码的方法)
  • 简单的定位(一个简单的工具方法可以自动找到对应于每个消息例如使用“SimpleClassName”,“INSTANCE_NAME”模式;您也可以在每个枚举上公开getMessage()方法,将实现委托给您的实用方法)
  • 验证您的本地化文件(您的单元测试可能会循环代码和文件上的每种语言,并找到所有不匹配的值)
  • 错误级别函数(我们使用与记录相同的级别:致命,错误,警告;日志决定很容易实现!)。为了便于其他开发人员找到适当的错误,我们使用了几个枚举(可能在同一个包中),根据它们的技术或功能领域对错误进行分类。

要ADRESS您的两个问题:

  1. 添加一个只需要增加一个实例来枚举,并在本地化文件的信息(但测试可以赶上后,如果忘记了) 。
  2. 随着几个枚举的分类,以及可能的javadoc,他们被引导使用正确的错误。
3

我不会在本地化中使用错误代码。可能有充分的理由使用错误代码(例如,能够测试发生哪种特定类型的错误),但本地化不是这些原因之一。相反,使用与用于其他消息本地化的异常相同的框架。例如。如果你在其他地方使用gettext,也可以在例外情况下使用它。这将使译者的生活更轻松。

2

您可以在中包含错误代码这是一个例外,从而获得最佳效果。

旧式函数返回错误代码出现错误的一个常见原因是在继续执行后续代码之前未能检查错误代码。一个例外不能被隐式忽略。消除错误来源是件好事。

错误代码允许:

  • 调用代码不同类型的错误之间进行区分。
  • 在非UI非本地化代码中发生错误时,由UI组件构建的消息。
  • 编写用户文档或疑难解答指南时可能有用的代码中的错误列表。

一些指引我发现有用:

  • 只有UI架构层建设和本地化信息给用户。
  • 当非UI层通过异常传递错误时,这些层可能会在构建消息时有选择地带有对UI有用的错误代码和附加字段。
  • 在Java中,当在UI层Enum中定义错误代码时,可以通过枚举器本身访问错误消息格式字符串。它们可能包含错误中附加数据的符号。
  • 在Java中,在原始语言的格式字符串中包含格式说明符中的参数索引,以便翻译人员可以在本地化消息中移动动态数据。