番石榴的前提條件checkNull，checkArgument

Question

我想檢查基類上的前提條件，以便知道子類型將始終使用有效的構造函數參數。

讓我們以一個構造器為例：

1. 接受2個或更多參數
2. 接受不同類型的參數
3. 對於一個參數，它執行多次檢查（例如String不為null 並且不為空）

在這種情況下，如何最好地使用番石榴前提條件方法？

在這樣的模擬示例中：（這是人為的！）

protected AbstractException(String errorMessage, Throwable errorCause) {
  super(errorMessage, errorCause);
  checkNotNull(errorMessage,
      ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK, "errorMessage");
  checkArgument(!errorMessage.isEmpty(),
      ErrorMessage.MethodArgument.CANNOT_BE_EMPTY_STRING_CHECK,
      "errorMessage");
  checkNotNull(errorCause, ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK,
      "errorCause");
}

我最終在檢查參數之前調用了super ，因為對super的調用需要是方法的第一行，盡管我可以做super(checkNoNull(errorMessage)) ，但是我不能使用checkArgument進行相同的包裝，因為這會返回void 。 因此，難題是：

• 我應該在哪里檢查所有參數？ 我不想為此創建一個生成器
• 我如何像虛擬的checkStringNotNullAndNotEmpty()一樣“分組”檢查
• 我是否應該考慮與匹配器框架集成？ （hamcrest，fest斷言...）

我使用外觀怪異的ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK，因為默認throw不包含錯誤消息，因此從測試方面，我無法將其識別為參數驗證失敗，而不是“任何” NPE？

我做錯了嗎？

Answer 1

這本來應該是一個評論，但是太長了。

• 如果超級控制器不會做它不應該做的事情， 那么在測試前調用super是無害的。
• 可以通過靜態構建器方法來防止它，您不需要構建器。 但這不值得。
• 我懷疑分組測試通常很有用； 如果是這樣，那么已經有這樣的方法了。 但是，如果您需要兩次以上這樣的具體事情，請自己編寫； 如果經常出現，請將其作為RFE報告給番石榴團隊。
• 我很確定，匹配器在這里是一個過大的殺傷力，因為您只是在創建一個例外，即，很少使用的東西（我希望）。 由於您的測試僅是運行時，因此並不能真正幫助您捕獲錯誤。 如果可以靜態地確保“正確地”構造的異常，那將是很好的，但是在純Java中這是不可能的。

更重要的是：您拋出的異常可能不如沒有所有檢查的異常。 假設用戶提供了原因，但沒有消息。 您認為這很糟糕，但是您可以使用沒有任何原因的NPE替換它。 更糟

查看Guava的Preconditions.format （私有包）。 他們可以先檢查正確數量的參數，但不能。 您可以提供太少或太多，這是一個錯誤，但忽略它是處理它的最佳方法。