听起来像一个答案很明显的愚蠢问题:)
仍然我冒险问只是加倍确定。
我们确实在使用下面给出的断言
ArrayList alProperties = new ArrayList();
assert alProperties != null : "alProperties is null";
问题是在断言上制作一个小而简单的文档是很困难的。有很多关于断言的书籍，但理想情况下，我想为新程序员提供关于使用断言之类的东西的非常简单的指南。顺便说一句，像 pmd 这样的工具会检查断言的正确使用吗？
提前致谢。
没有合理的理由使用这样的断言。如果由于某种原因无法创建对象，则甚至不会到达您的断言（例如，因为抛出异常或 VM 退出）
在 Sun 的Programming with Assertions中有一些关于使用断言的相当简洁的指南。那篇文章建议断言应该用于诸如内部不变量、控制流不变量、前置条件、后置条件和类不变量之类的东西。
不，您不想检查对象创建。
如果对象创建失败，jvm 将抛出 OutOfMemoryError，如果发生这种情况，您可能无论如何都无法修复。
这就像不信任 JVM。关于你认为给定的东西，你必须在某处画一条线......
在 Java 中，每次调用 new 都会返回对新对象的非空引用，或者引发异常或错误。在第一种情况下，您的断言为真，在第二种情况下，将无法到达断言，因为您在下一个匹配的 catch 块中结束。
这个断言测试你的 Java 实现是否被破坏，在这种情况下你甚至不能依赖断言。所以我不会做出这样的断言。使用 assert 来限制语言不强制执行的对象（例如，如果您的方法传递了一个 null 但不应该传递的参数）。
这个断言只会弄乱你的代码，它相当于这个断言：
boolean a = true;
assert a : "A should be true"
您不应该测试您的 JVM，除非这是您的程序的重点（例如，它是您正在制作的 JVM 的测试套件）。相反，您应该测试您的前置条件、后置条件和不变量。有时这些测试太基础或太昂贵。
前置条件可能只应该出现在方法的开头（如果您有很长的方法，那么您应该将该方法分成小部分，即使它们都是私有的）。
后置条件应该清楚您返回给调用者的内容，您不测试 sqrt 函数是否只返回了 sqrt，但您可能会测试它是肯定的以明确您的期望（也许稍后的代码使用复数，而您的未对此进行测试）。而是在底部留下评论。
不变量通常也无法测试，您无法测试您当前的解决方案是否是正确的部分解决方案（见下文）——尽管这是使用尾递归编写东西的好处之一。相反，您使用注释声明不变量。
如果您在外部调用事物，您还将使用断言，例如在您的示例中，如果您有ArrayList.Create()，那么您可以选择断言检查null。但这只是因为您不信任其他代码。如果您编写了该代码，则可以将断言（注释或其他）放在工厂方法本身中。
int max(int[] a, int n) {
assert n <= a.length : "N should not exceed the bounds of the array"
assert n > 0 : "N should be at least one"
// invariant: m is the maximum of a[0..i]
int m = a[0];
for( int i = 1; i < n; n++ ) {
if( m < a[i] )
m = a[i];
}
// if these were not basic types, we might assert that we found
// something sensible here, such as m != null
return m;
}
我不确定是否完全理解你的问题，但我认为这种断言是不必要的。
创建实例时，如果程序流继续，则该实例不是空引用。
您希望 ASSERTS 检查程序的属性或不变量。一个好的文档来教这个应该鼓励程序员以系统/有条理的方式思考这些属性。
如果断言失败，相信我，你将遇到比仅仅处理断言更大的问题。
如果该断言失败，我认为该是我寻找另一份工作的时候了，因为计算机无法正常运行，而当这种情况发生时，所有地狱都会崩溃！