在我的单元测试中，我测试了一个预期 RuntimeException 的方法，我想将我的组件抛出的那些与方法中调用的代码抛出的区分开来。
创建自定义异常类型是不必要的，并且如果方法抛出相同的异常类型但出于不同的原因（例如无效参数异常。
似乎告诉他们的唯一方法是消息或错误代码。因为在开发过程中可以更改消息，所以错误代码似乎是唯一可靠的选择。
创建错误代码系统的最佳做法是什么，这样它们就不会与外部包冲突，例如。第三方库？
【问题讨论】：
标签： java unit-testing exception
创建自定义异常类型是不必要的，并且不能解决 如果方法抛出相同的异常类型但不同的问题 原因，例如无效参数异常。
为什么你认为没有必要？这是你应该做的。派生您自己的自定义异常类，从您的代码中抛出它们的实例并在外部捕获它们（在您的单元测试中）。可以重复 catch 语句以预期多个不同的异常类：
try {
// something
} catch (MySpecificException e) {
// you know that your code threw this
} catch (Exception e) {
// this is coming from somewhere else
}
【讨论】：
--编辑--
抱歉，我没有看到 java 标签。即使以下示例使用 PHP 结构，这些原则仍然适用。
--原创--
我只在少数非常特殊的情况下使用自定义异常代码，并将这些代码存储在自定义异常类中，该类扩展了默认异常类。它们作为常量存储在类中，因为值并不重要，但上下文很重要。
考虑：
class CoreLib_Api_Exception extends Exception
{
const EXCEPTION_FORMAT = '%s (%s): %s';
const CODE_FILE_DNE = 100;
const CODE_DIR_BASE_EQUALS_REMOVE = 101;
const CODE_XML_READER_UNABLE_TO_OPEN = 200;
const CODE_XML_READER_UNABLE_TO_READ = 201;
}
// Example usage
class CoreLib_Api_Reader
{
protected function getReader()
{
$reader = new CoreLib_Api_Xml_Reader();
if (!@$reader->open($this->getFileUri())) {
$e = new CoreLib_Api_Exception(sprintf('Could not open %s for parsing', $this->getFileUri()), CoreLib_Api_Exception::CODE_XML_READER_UNABLE_TO_OPEN);
throw $e;
}
}
}
// Calling code
try {
$reader = CoreLib_Api_Reader();
$reader->setFileUri($fileUri);
$reader->getReader();
} catch (Exception $e) {
// If code is anything other than open, throw it
if ($e->getCode() !== CoreLib_Api_Exception::CODE_XML_READER_UNABLE_TO_OPEN) {
throw $e;
}
$e = null;
$reader = null;
}
通过使用异常代码，我可以检查确定阅读器是否无法打开文件，如果是则忽略异常并继续，否则抛出异常并中断流程。
如果我的一个异常代码与第三方异常代码发生冲突，正如我之前提到的，使用常量并不重要，上下文将决定我要匹配哪个代码。
【讨论】：
我为预期的 RuntimeException 测试一个方法
我认为这是一个错误。 RuntimeException 应仅用于指示代码本身可以检测到的代码中的错误。测试应该只测试指定的（定义的）行为。但是当某些代码中存在错误时，它的行为是未定义的（谁知道错误可能在哪里或它可能会做什么）。因此，尝试指定某些代码应该抛出的RuntimeExceptions 是没有意义的；这就像指定代码在“存在错误时”的行为方式。向维护程序员（很可能就是你）抛出带有特定消息的特定 RuntimeExceptions 应该被视为一种礼貌。
【讨论】：
RuntimeException，但合同不应该指定那是什么。甚至它肯定会发生。