在私有实用程序类构造函数中使用的首选 Throwable 是什么？

Question

Effective Java（第二版），第 4 项讨论使用私有构造函数来强制不可实例化。 这是书中的代码示例：

public final class UtilityClass {
    private UtilityClass() {
        throw new AssertionError();
    }
}

但是，AssertionError 似乎不是正确的抛出方法。 没有任何内容被“断言”，这就是 API 定义 断言错误。

在这种情况下是否有不同的 Throwable ？ 人们通常会抛出一条带有消息的常规Exception吗？ 或者为此编写自定义Exception 是否很常见？

这是相当微不足道的，但最重要的是，我想我只是从风格和标准的角度对它感到好奇。

Answer 1

有一个断言：“我断言这个构造函数永远不会被调用”。 所以，事实上，AssertionError 在这里是正确的。

Answer 2

我喜欢包括布洛赫的评论：

// Suppress default constructor for noninstantiability

或者更好地将其放入错误中：

private UtilityClass()
{
    throw new AssertionError("Suppress default constructor for noninstantiability");
}

Answer 3

UnsupportedOperationException 听起来是最合适的，尽管检查异常会更好，因为它可能会警告某人在编译时错误地实例化该类。

Answer 4

IllegalAcessError 怎么样？ :)

Answer 5

当代码需要将 JUnit 作为依赖项包含在内（例如在 Maven 测试范围内）test，则直接转到 Assertion.fail() 方法并受益于清晰度的显着提高。

public final class UtilityClass {
    private UtilityClass() {
        fail("The UtilityClass methods should be accessed statically");
    }
}

当超出测试范围时，您可以使用类似以下内容的内容，这需要静态导入才能像上面一样使用。 import static pkg.Error.fail;

public class Error {
    private static final Logger LOG = LoggerFactory.getLogger(Error.class);
    public static void fail(final String message) {
        LOG.error(message);
        throw new AssertionError(message);
        // or use your preferred exception 
        // e.g InstantiationException
    }
}

其中用法如下。

public class UtilityClassTwo {
    private UtilityClassTwo() {
        Error.fail("The UtilityClass methods should be accessed statically");
    }
}

在其最惯用的形式中，它们都归结为：

public class UtilityClassThree {
    private UtilityClassThree() {
        assert false : "The UtilityClass methods should be accessed statically";
    }
}

内置异常之一，UnsupportedOperationException 可以被抛出到
指示“不支持请求的操作”。

 private Constructor() {
    throw new UnsupportedOperationException(
            "Do not instantiate this class, use statically.");
}

Answer 6

不不不，恕我直言，永远不要抛出AssertionError，除非它来自断言。如果您想要在这里出现 AssertionError，请使用 assert 抛出它（假）。 然后阅读代码的人可以稍后找到它。

更好的是，定义您自己的异常，例如 CantInstantiateUtilityClass。 然后你将得到这样的代码

try {
    // some stuff
} catch (CantInstantiateUtilityClass e) {
    // react
}

，以便捕手的读者知道发生了什么。

---

让我注意一下，标准仍然将AssertionError定义为失败断言的结果，而不是某些初学者认为应该抛出的结果明确定义的信息异常的地方。 遗憾的是，良好的异常纪律可能是 Java 编程中最不值得鼓励的技能。

Answer 7

断言被破坏意味着您已经破坏了代码的合同规范。 所以这是正确的事情。

但是，正如我假设您将私下实例化一个实例一样，它也会调用构造函数并导致错误 - 除非您有另一个构造函数？

Answer 8

您可以创建自己的类来扩展 Throwable，例如：

class NoninstantiabilityError extends Throwable

这具有以下优点：

• 名称表明了问题
• 因为它直接扩展了 Throwable，所以不太可能被捕获由于
• 它直接扩展了 Throwable，因此会对其进行检查，并且意外调用相应的构造函数将需要捕获异常用法

示例：

public final class UtilityClass {
    private UtilityClass() throws NoninstantiabilityError {
        throw new NoninstantiabilityError();
    }

    ...
}