1
  private void httpGetAccessToken() throws IOException {
        String url = accessTokenUrl.getValue();
        logger.debug("access token url : " + url);

        String response = WechatHttpClient.post(url);
        logger.debug("access token response : " + response);

        Map<String, Object> map = JSONObject.parseObject(response);
        accessToken  = map.get("access_token").toString();
        instant = Instant.now();

        logger.debug("access token value = " + accessToken);
        logger.debug("access token gain time is : ", instant.toString());
    }

There are too much logging statements above. Is this normal? or should I remove some of them, or is there any technique to solve this problem, like AOP or design pattern?

Max
  • 25
  • 4
  • 1
    If you really want them to go away, just comment them out. – ifly6 Jan 24 '18 at 01:00
  • You can also change the logging level from `debug` to `info` to reduce the amount of logging based on what you're monitoring – MadProgrammer Jan 24 '18 at 01:03
  • Can you modify the code? – Roman C Jan 24 '18 at 01:48
  • Maybe OP searches for a way to outsource logging such that it doesn't clutter the actual logic that much. In that case he searches for a pattern advice or library, that kind of stuff. Therefore see questions like [(1)](https://stackoverflow.com/questions/4178392/how-to-separate-logging-logic-from-business-logic-in-a-c-program-and-in-a-c-o) and [(2)](https://softwareengineering.stackexchange.com/questions/344218/is-it-possible-to-keep-logging-code-completely-outside-the-business-logic). – Zabuzard Jan 24 '18 at 02:11
  • I tend to agree. The logging lines get in the way of reading and understanding the code itself. And obviously, commenting them out won't help. The best thing to do depends on what the purpose of all this logging is. Is it just that there's a developer somewhere who doesn't know how to use a debugger? – Dawood ibn Kareem Jan 24 '18 at 02:17
  • @Zabuza These links are very useful – Max Feb 02 '18 at 01:36

1 Answers1

0

Choose a simple solution.

Have one log.debug statement in the end, and log all the parameters there: access token url, response, token gain value, and time. Also, since these statements provide information for every step, my hunch is that these info pieces are meant to troubleshoot. Use the log level as trace in that case.

TL:DR;

You ask,

"There are too much logging statements above. Is this normal?"

Answer is subjective. It is normal in the cases where it is meant to be an alternative to debugging using an IDE. We call it micro-logging. Good to troubleshoot, but hits performance in the prod environment because of too much I/O. Imagine this mirco-logged piece of code running in production with at least 500 threads accessing it per second. Also, the log will look like a nightmare.

You ask

" ...is there any technique to solve this problem"

It is not a problem. Code tweak is required. make sure log statements are less and exceptions are caught. In your code below, the url are response can possibly be null. Catch these exceptions or else there may be times when any amount of logging will end up being futile. for exceptions which are caught, use a log.error in the catch block, with exception.getMessage().

    String url = accessTokenUrl.getValue();
    logger.debug("access token url : " + url);

    String response = WechatHttpClient.post(url);
    logger.debug("access token response : " + response);

    Map<String, Object> map = JSONObject.parseObject(response);
    accessToken  = map.get("access_token").toString();
    instant = Instant.now();

You ask,

..like AOP or design pattern ?

Again subjective, and varies according to applications. As a simple and naive example, you may want to use AOP for cases where multiple components access a common method doSomething(), each with a request with different data. You can you an AOP based solution to log the source of the request, and the non-sensitive request data in the log method. Call the log method "Before" the doSomething(). Start here to delve into the details

Amal Gupta
  • 452
  • 4
  • 13