1

Some code I wrote was sent back to me during peer review, telling me to add logging to the start of each case in a switch statement in a servlet (Java, if that matters), so if something goes wrong, we can see where. I figured that doesn't make sense, as we log entire stack traces anyway, but the response I got to that was

"It's standard practise throughout the entire industry."

They didn't have time to debate, which is fair enough, and I'll do what they say. But this hasn't been my experience in other companies. I just want to know, is it really some kind of standard practise? What is it useful for?

As an example of what I mean:

switch (task) {
    case VIEW:
        logger.info("inside VIEW for taskPage");
        {...}

    case EDIT:
        logger.info("inside EDIT for taskPage");
        {...}
|improve this question
  • 3
    The important point here is not that you're dealing with a switch. All kinds of situations use switch statements, from central dispatching logic to trivial formatting logic. What was probably meant that it is standard to log branches of central, important logic such as the dispatching within an important servlet. – Kilian Foth Jun 28 '17 at 7:05
  • Damn. You're right. I may have just asked this over a miscommunication. I can't remove the question from the phone app, can I? – AlbeyAmakiir Jun 28 '17 at 7:17
  • You could search your code base and see if this is a common practice. – JeffO Jun 28 '17 at 12:12
  • "It's standard practise throughout the entire industry." No it's not. Given the breadth of today's software world, there are no standard practises throughout the entire industry. – adelphus Jun 28 '17 at 14:23
  • 1
    Why would you put a separate logger.info call inside each case statement instead of a single call before performing the switch? As others said, no it is not standard practice across the industry, even if by "standard practice" one simply means a lot of companies do it that way. However, if it is "standard practice" at your company then it is worthwhile to conform for the simple reason that consistency makes everyone's development life better because it makes the inconsistent things (usually the source of problems) jump out all the more easily. Even if that consistency might be a bad idea. – Dunk Jun 28 '17 at 22:10
3

If it is its a bad practice.

I think its fair to say that there is a lot of this kind of 'debug logging' out there. By which I mean logging which enables you to follow the flow of logic through the code.

However, the reason I say that its a bad thing is that:

  • Its almost impossible to log enough information to show you the entire flow. You will see people logging the method name and all parameters on each method for example, and still want this kind of conditional branch logging
  • Even a small amount of this kind of logging generates huge volumes of logs. Even if you do catch an anomalous situation, finding it will be a nightmare
  • It should be possible to follow the logic via really debugging, which gives you far more insight into whats going on that trying to interpret logs.

Instead, try to log things to do (input) and results of things done (output). This allows you to spot unusual outcomes and replay them in an integration test if required.

ie. Log OrderPlaced {orderstate} and OrderProcessed {orderstate}

Avoid logging non errors inside your business logic ie. "reducing price by 2% because its a sale"

|improve this answer
  • I totally disagree with what the OP is being asked to do. However, did you ever hear of Excel? If you log in a consistent format (e.g. .csv), which can usually be done without the calling code even knowing, then opening your log file in excel allows you to do some pretty sophisticated analysis almost trivially and at the same time allows someone else to read via standard text. Yes, debugging is great, but where do you begin debugging when all you get is a log entry that shows a stack trace where the error occurred in the field? I agree 'too much' logging is bad, but so is 'too little'. – Dunk Jun 28 '17 at 22:02
  • i would recommend putting the logs in elasticsearch. We are talking gigabytes here. But thats what i mean about storing the input and output of the process. make sure you can repeat the process in debug mode if required. – Ewan Jun 28 '17 at 23:02
  • If you are referring to so much debug that Gigabytes of logging is happening then I agree that would certainly be a bad practice. However, I do think it is important to log enough to be able to determine how you may have ended up hitting the error. I would certainly expect that by the time the app is fielded that all "expected" cases have been tested and handled. Thus, if you hit an error it is because something happened that you didn't think of. You need enough logging to have a clue on how to reproduce the error. Debugging doesn't help if you can't reproduce the error. – Dunk Jun 28 '17 at 23:24
  • As for elasticsearch - Don't underestimate how many people know how to effectively use Excel. If your logs have useful and readily extractable information then you'll be surprised at how creative people from different disciplines can be at extracting and analyzing data from your log files to suit their unique purposes. – Dunk Jun 28 '17 at 23:27
  • Have a look at, logstash/elasticsearch/kibana i think you will find its much better than excel – Ewan Jun 28 '17 at 23:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.