您认为在异常中使用错误代码指定错误类型是否可以? 请看一下这段代码:
public class MyException extends Exception {
public static final String ERROR_CODE_INVALID_NAME = "";
public static final String ERROR_CODE_INVALID_ID = "";
...
private String errorCode;
public MyException(String message, String errorCode) {
super(message);
this.errorCode = errorCode;
}
public String getErrorCode() {
return errorCode;
}
}
我知道在这个例子中使用enum而不是字符串会更好,但我实际上关心的是错误代码的概念。您认为异常层次结构在这里会更好吗?我无法找到任何权威来源,说明异常中的错误代码是反模式的。 THX。
答案 0 :(得分:8)
时,错误代码非常有用
所以,大部分时间,我都没有在错误代码中看到任何附加价值。我更喜欢在日志文件中找到的异常层次结构或至少清晰的错误消息(即使在程序员离开公司2年后也是如此)。
如果您对错误代码有要求 - 解决方案也不错。考虑在中央存储库(属性文件)中收集所有错误代码,以便您可以轻松地交换完整集:
myexception.ERROR_CODE_INVALID_NAME=text or number
myexception.ERROR_CODE_INVALID_ID=text or number
答案 1 :(得分:4)
根据我的经验,异常代码主要用作用户的信息消息。
我甚至没有看到有人试图解析一般异常消息以便采取不同的反应取决于错误代码,通常是通过异常层次结构完成的。
另一方面,可能很难为每个特定情况创建新的异常子类,然后使用异常代码
例如,如果对于用户代码,它不会计算为什么事务失败,它应该以任何方式回滚它,但对于最终用户来说,重要的是它发生的原因(错误的参数,数据库连接或其他)。
因此,总而言之,如果您期望处理不同情况的不同方法,最好使用不同的异常类型,但如果您应该以相同的方式处理几个问题但只通知用户特定原因则更容易使用异常码。
答案 2 :(得分:2)
从内存和时间方面来看,从性能方面创建复杂异常层次结构的堆栈跟踪是非常昂贵的,因此如果您为可以通过3-4个静态错误代码解决的问题创建复杂的自定义异常层次结构......我会更喜欢错误代码选项。一般来说,我更喜欢使用运行时异常(未在方法签名中检查)捕获已检查异常的深度方法很少过时IMO。
答案 3 :(得分:2)
如果您希望以不同的方式(在代码中)做出反应,具体取决于导致异常的原因(无效名称或无效ID),那么我建议您使用不同的例外。
如果没有,那么您甚至不需要getErrorCode()
方法,只需将错误代码添加到异常消息中,异常将为您提供调试所需的所有信息。
答案 4 :(得分:2)
我通常使用两者的组合。
您需要对例外进行分类并做出设计决策。
例如,您可以使用诸如异常来源,类型,影响和处理等参数来对异常进行分类。如果异常属于同一类别,请使用其中的错误代码。使用层次结构来处理不同类别的异常。
如果您选择Exception Handling一个重要参数,您可以根据您希望如何处理它们来选择这两个选项: