Java記錄器的輸入/退出方法中的參數

假設使用java.util.logging.*，在myLogger.entering(...)和myLogger.exiting(...)中使用什麼適當的參數？如果這些始終應該是源類名稱和源方法名稱，那麼爲什麼方法不會找到信息本身，而不是向我們詢問它？方法文檔說：Java記錄器的輸入/退出方法中的參數

這是一種方便的方法，可用於記錄方法的入口。記錄消息「ENTRY」，日誌級別FINER和給定sourceMethod和sourceClass的LogRecord。

這是一種方便的方法，可用於從方法中記錄返回。記錄帶有消息「RETURN」，日誌級別FINER以及給定sourceMethod和sourceClass的LogRecord。

如果我們簡單地硬編碼的方法名，即使用" "？我可能不正確的理由是，如果我的getMethodName()做的是可以接受的重度使用，那麼日誌系統會自己做，而不是要求我們的方法名稱。

private static void methodNine() { 
    logger.entering(LogTest.class.getName(), getMethodName()); 

    logger.exiting(LogTest.class.getName(), "sourceMethod"); // sourceMethod=? 
} 

/** @return The current method name. */ 
private static String getMethod() { 
    return Thread.currentThread().getStackTrace()[2].getMethodName(); 
    //[0]=getStackTrace, [1]=getMethod, [2]=<method name we're looking for> 
}

來源

2014-12-31 Daniel

假設使用的java.util.logging的*，這將是適當的論點myLogger.entering（...）和myLogger.exiting使用（...）？

根據documentation，它是源類名稱和源方法名稱。然而，在匿名類的情況下彎曲規則有時很好，可以包含聲明類和方法名以及由特殊標識符分隔的匿名方法和類名。權衡是如果過濾器需要一些標準的類/方法格式，某些LogRecords的filtering可能會變得棘手。

如果這些總是被認爲是源類名和源方法名，爲什麼不方法找到的信息本身，而不是問我們呢？

創建日誌API時computing the callsite at runtime was expensive compared to just supplying a constant.今天仍然有成本。

對於dynamic proxies使用給定的方法名稱而不是處理程序類和方法是很好的。此外，Java本地接口在計算native code中的當前方法時可能會遇到問題。

我們應該簡單地硬編碼方法名稱，即使用「」？我可能不正確的理由是，如果我的getMethodName（）所做的事情對於大量使用來說是可以接受的，那麼日誌記錄系統會自己做，而不是要求我們輸入方法名稱。

取決於您的要求。如果您認爲'getMethodName（）'今天和X年後的速度足夠快，那麼您必須確定是否存在此模式的任何編碼債務。有一個JEP草案可以創建Efficient Stack Walking API，因此您可能可以在將來提高性能。

您可以創建一個名爲'methodName'的局部變量作爲每個方法的第一行，並執行相同的操作。

來源

2014-12-31 20:31:22 jmehrens

Java記錄器的輸入/退出方法中的參數

回答

相關問題