• (cs) in reply to qbolec
    qbolec:
    Actually it might be a good idea, to have logger plugged everywhere throughout the code as long as you have a nice way to turn it on/off, preferably at a module level granularity, when the interpreter is so slow that the impact is negligible anyway. In compiled languages you usually have preprocessor and thus can define log(x) to do nothing. But then you can not just turn it on/off on production. I can imagine some crazy way to force JITed languages to change implementation of log(x) on fly. Since I can, then probably it is already built in into .NET or something. But then again, I think it would be much better to have just a Trace mechanism built in into the interpreter/runtime environment/ or just a debugger, so that the developer doesn't have to echo each line of code to log(x).

    I found, that Math has a log function, but it doesn't do what I need, though.

    Well The I guess it's time to confess the biggest WTF i have made to day, and it was along the lines indicated above.

    Some 8 years ago I was making an integrated process control and data acquisition system in Perl. We used Perl as it made it easy to use web interface for the control system as well as the data acquisition.

    Well in that process I made a bit utility module including various functions (web controls, data location directory information, user identification etc., Yes I know now it is not a good idea to just glob things in a big pile).

    I needed an error log function (logging if a file could not be opened for instance), and as it would be used quite a lot of places, i called it just log() which returned 0 or 1 depending on if it was successful in writing the information to the errorlog.

    I'm sure you can see where this goes and I which I could that then. Things worked fine for some 6 months before I needed to make some data processing scripts to make some calculations on the data. I still needed some functions from the library, so I just included it as I always did, and as I was now doing math, I needed the natural logarithm of the result of a division, come along the log function in Perl right? :-)

    Took hours to find out why the results was slightly off what they should have been.......

    I had to use an external logarithm program to circumvent my own stupidity before I had the time to do it right.....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer.

  • Henk (unregistered)

    I'd suggest the following improvement, right before the first statement:

    logFile.debug("Logging informational message."); logFile.info("START: Assigning variables.");

    It's necessary for the case where the logFile.info() method contains a bug.

  • The Typinator (unregistered) in reply to Anonymous
    Anonymous:
    Inigo Montoya:
    To show that you're using a word ironically, you put it in quotes.
    Where the hell did you learn English?
    Spain?
  • Anon (unregistered) in reply to Spoc42
    Spoc42:
    I have had the opposite effect today. Access 2003 crashing while opening a form (sometimes) and crashing when I pressed a particular button (always). When running in debug mode, everything worked just fine; when running full tilt, it crashed. Lost me about 6 hours until I got 10 mS delays in the right places to *slow* it down.

    What is REALLY fun in MS Access 2003 is when just stepping through code fixes it.

  • trwtf (unregistered) in reply to trwtf
    trwtf:
    boog:
    My point is that there are so many methods for debugging code; all of them can be just as useful as a debugger (in some situations more so, in some situations less).

    As long as your code ends up de-buggered in the end, that's all that matters.

    I'm sorry. I attempted humour hear, but in retrograde, it failed.

  • geekgirl (unregistered) in reply to Anonymous
    Anonymous:
    Where the hell did you learn English? I'd like to see a citation for that.

    Google "scare quotes" and you'll get plenty. Here's an excerpt from the Chicago Manual of Style's chapter 7.55:

    Chicago Manual of Style:
    7.55 “Scare quotes”. Quotation marks are often used to alert readers that a term is used in a nonstandard (or slang), ironic, or other special sense.

    Not saying that it's imperative to use the quotes, but notme wasn't pulling that rule out of his/her ass.

  • frits (unregistered) in reply to trwtf
    frits:
    trwtf:
    boog:
    My point is that there are so many methods for debugging code; all of them can be just as useful as a debugger (in some situations more so, in some situations less).

    As long as your code ends up de-buggered in the end, that's all that matters.

    I'm sorry. I attempted humour hear, but in retrograde, it failed.

    I'm sorry, I attempted humor there, but it just didn't work out.

  • (cs) in reply to frits
    frits:
    frits:
    trwtf:
    boog:
    My point is that there are so many methods for debugging code; all of them can be just as useful as a debugger (in some situations more so, in some situations less).

    As long as your code ends up de-buggered in the end, that's all that matters.

    I'm sorry. I attempted humour hear, but in retrograde, it failed.

    I'm sorry, I attempted "humor" there, but it just didn't work out.

    FTFY

  • Anon (unregistered)

    logFile.debug("Setting timeout to 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 9999999999999999999...");

  • Ibi-Wan Kentobi (unregistered) in reply to evertras
    evertras:
    ...it was specific to his environment, and it was crashing in such a strange place that I wouldn't have found it if I hadn't done SuperLogging.

    What, like the back of a Volkswagen?

  • Bill Sorensen (unregistered)

    The WTF isn't the logging, it's manually instrumenting the code (and all the unnecessary comments).

    In .NET you can log entry, exit, and arguments of desired methods without changing the code using PostSharp (http://www.sharpcrafters.com/). This code looks like Java; I suspect AspectJ would do the same thing. AOP (Aspect-Oriented Programming) is perfect for this.

  • anonymous (unregistered) in reply to AlexC

    While it is possible for the debugger to cause issues in your code, it's likely that a bug was causing the debugger to have issues in the first place.

    The debugger interrupts processes and changes behavior. If you have an issue in your code, it's possible that this process of changing behavior causes the issue to actually be a problem, where as without the debugger, by dumb luck your code doesn't run into the problem condition.

    The opposite is also commonly true. Sometimes your code can run perfectly within the debugger and crash and burn within the debugger. One likely cause of this is the debugger causing memory to be allocated differently.

    AlexC:
    I do hate it when people come on and defend mad practices in coding but I once had to fix a piece of problem code existed in a routine that, when run in a debugging tool (I don't want to say which one), would crash and die horribly. I spent some really long hours trying to fix the issue and then as a last gasp attempt I just ran it outside the debugger it worked perfectly. I was stung by that and it stayed with me to never trust debuggers 100%. However, obviously this code should never, ever make it to a production build.
  • trwtf (unregistered) in reply to WhiskeyJack
    WhiskeyJack:
    frits:
    frits:
    trwtf:
    boog:
    My point is that there are so many methods for debugging code; all of them can be just as useful as a debugger (in some situations more so, in some situations less).

    As long as your code ends up de-buggered in the end, that's all that matters.

    I'm sorry. I attempted humour hear, but in retrograde, it failed.

    I'm sorry, I attempted "humor" there, but it just didn't work out.

    FTFY

    Thanks for defending me their. I hate that frits guys.

  • frits (unregistered) in reply to trwtf
    trwtf:
    WhiskeyJack:
    frits:
    frits:
    trwtf:
    boog:
    My point is that there are so many methods for debugging code; all of them can be just as useful as a debugger (in some situations more so, in some situations less).

    As long as your code ends up de-buggered in the end, that's all that matters.

    I'm sorry. I attempted humour hear, but in retrograde, it failed.

    I'm sorry, I attempted "humor" there, but it just didn't work out.

    FTFY

    Thanks for defending me their. I hate that frits guys.

    Aww, don't hate me. I'm just playing around, I don't mean to be mean. I'm sorry, I'll never do it again.

  • (cs) in reply to frits
    frits(unregistered):
    trwtf:
    WhiskeyJack:
    trwtf:
    trwtf:
    trwtf:
    boog:
    My point is that there are so many methods for debugging code; all of them can be just as useful as a debugger (in some situations more so, in some situations less).

    As long as your code ends up de-buggered in the end, that's all that matters.

    I'm sorry. I attempted humour hear, but in retrograde, it failed.

    I'm sorry, I attempted "humor" there, but it just didn't work out.

    FTFY

    Thanks for defending me their. I hate that frits guys.

    Aww, don't hate me. I'm just playing around, I don't mean to be mean. I'm sorry, I'll never do it again.

    I can see that surrogate is working out for me. [image]

  • Me (unregistered) in reply to TST
    TST:
    For a medical product, these logs are great because you can track everything that was done.

    Maybe I'm too anal, but I can't really see the WTF here. If the code passage is mission-critical I can understand the massive logging capabilities.

    TST

    Since this looks like a Java webapp it would be easy to add Spring support (if it's not already used) and implement an interceptor to log critical method calls. Keeps the code clean and could be used to take responsibility for tracking and monitoring away from the individual developers to a team that knows and decides what needs to be tracked.
  • Stark (unregistered) in reply to Bus Logic
    Bus Logic:
    nitehawk:
    In fact in my career I would say I get brow beat due to my age without regard to my experience. (10 years industry experience at 29). Then when I do get to an age where I can perform the same, I get scoffed because of the low amount of time at the company.
    That's funny, I'm also 29 years old with 10 years industry experience; the only difference is that I'm a senior developer and a team lead. Maybe it's not your age that's the problem? No offence meant by that, I just mean maybe you're working for a crappy company that doesn't recognise your talent?

    Or maybe he keeps alienating everyone and jumping ship. So after 10 years of working he still hasn't established the experience/skill set involved with lead positions, and no company is willing to hire a lead from outside based on 10 years of experience as a peon.

    (Also not trying to be offensive, but the phrase "low amount of time at the company" says it all.)

  • (cs) in reply to Bus Logic
    Bus Logic:
    nitehawk:
    In fact in my career I would say I get brow beat due to my age without regard to my experience. (10 years industry experience at 29). Then when I do get to an age where I can perform the same, I get scoffed because of the low amount of time at the company.
    That's funny, I'm also 29 years old with 10 years industry experience; the only difference is that I'm a senior developer and a team lead. Maybe it's not your age that's the problem? No offence meant by that, I just mean maybe you're working for a crappy company that doesn't recognise your talent?

    I am 10 years down the road from both of you with a little more experience (25 years), and I'll tell you that it doesn't end. There is no such thing as exactly right - so you will always be too young or too old.

    What happens here is simple math though - people subtract 10 from 29 and figure you started 'getting experience' at age 19 - which is too young to get any actual experience, so they don't even look at your 10 years. I will say that I started at age 14 - which is actually a lie - age 14 is when I released my first commercial software. I can prove this too - but it doesn't matter. Any experience you get as a teenager almost counts against you. The fact that I look 10 years younger than I am doesn't help either. People basically think I'm lying about the experience.

    So, I've stopped putting the number. Instead I make sure they can see I was working for an internet company in 1999, and going to college before that. Most people think the internet was created around 1995, and there wasn't any worthwhile computer stuff before then, so it's really just your 'internet age' they are interested in. This is of course, completely stupid, as those of us who started in the 80s, before "everything is the web", actually have a better foundation in programming principles.

  • (cs) in reply to geekgirl
    geekgirl:
    Anonymous:
    Where the hell did you learn English? I'd like to see a citation for that.

    Google "scare quotes" and you'll get plenty. Here's an excerpt from the Chicago Manual of Style's chapter 7.55:

    Chicago Manual of Style:
    7.55 “Scare quotes”. Quotation marks are often used to alert readers that a term is used in a nonstandard (or slang), ironic, or other special sense.

    Not saying that it's imperative to use the quotes, but notme wasn't pulling that rule out of his/her ass.

    There is a whole world of folks out there who take that rule too far using quotes for simple emphasis, where you would normally use bold face, or ALL CAPS. There is a whole web site dedicated to this mistake...

    http://www.unnecessaryquotes.com/

  • (cs) in reply to frits
    frits:
    frits(unregistered):
    I'm sorry, I'll never do it again.
    I can see that surrogate is working out for me.
    Is he? Or is he making promises that you will end up being expected to keep?
  • Buddy (unregistered)
    Brian Kernighan:
    The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
  • (cs) in reply to Anon
    Anon:
    logFile.debug("Setting timeout to 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 9999999999999999999...");

    logFile.debug("Setting timeout to: "); for(int i=0;i<300;i++) { logFile.debug("9"); }

  • Oops (unregistered) in reply to @Deprecated
    @Deprecated:
    Anon:
    logFile.debug("Setting timeout to 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 999999999999999999999999999999999999999999999999999999999999 9999999999999999999...");

    logFile.debug("Setting timeout to: "); for(int i=0;i<300;i++) { logFile.debug("9"); }

    Close, but forgot the ellipsis.

  • monkeyPushButton (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Mike:
    WhiskeyJack:
    Check your compass; you're obviously not going north.
    Check your globe, in both cases of the northpole (magnetic and real) he will never hit Canada.
    Indeed, he won't. But if you start at Anchorage and go north, you see a whole lot of land (most of Alaska), then maybe a bit of water (depending on the season), then a whole lot of ice, then a place where you can only go south.
    What about Santa and his workshop?
  • Artemus Harper (unregistered)

    Since most things are logged as debug, they don't get logged under normal settings. For Java you can log under several levels:

    SEVERE (highest value) WARNING INFO CONFIG FINE FINER FINEST (lowest value)

  • LANMind (unregistered) in reply to Bus Logic
    Bus Logic:
    Yeah, I hear this a lot from juniors.
    +1
  • Anonymous (unregistered) in reply to boog
    boog:
    Obviously it's better if your method of measuring the economic value (in terms of time and effort) is based on how many data you get from the debugger. However, I personally find it time-consuming to sift through a lot of meaningless information, so aside from situations where having every bit of info you could possibly want is useful, I don't see the economic benefits myself.

    I'd much rather take a few seconds to sprinkle some assert statements throughout the known problem area and let the error conditions surface on their own (but even that doesn't work in all situations).

    I see where you're coming from but surely this is the purpose of breakpoints? Figure out where you need the info (ie. where you would manually add a line of log code) and set a breakpoint. No need to step through reams of code, no need to digest info you're not interested in. Although I do concede that there are times when logging is superior - like in a loop, where you need to traverse many iterations before you get to the point you're interested in. However, to dispute my own point, most modern debuggers allow you to set hit-counts on breakpoints so they only break after the nth hit.

    boog:
    My problem with debuggers is that for many programmers, running the debugger becomes a knee-jerk reaction whenever something seems amiss. No thought goes into where the root cause of the problem might be and what might be the best method to identify it. They just fire up the debugger and step through the code.
    I'm with you on that one, some people certainly do abuse the tools and I agree that blindly stepping through code is no substitute for using your brain to figure out what's going wrong.
    boog:
    My point is that there are so many methods for debugging code; all of them can be just as useful as a debugger (in some situations more so, in some situations less).
    Fair play, I can't argue with that.
  • . (unregistered) in reply to LANMind

    But where is XML in this?

  • Bob The Builder (unregistered)

    If he actually changes the logging level, depending on the need (INFO,DEBUG,ERROR, etc.) it's not as bad as the code reads...

  • Obnoxious Frog (unregistered) in reply to random internet wanker
    random internet wanker:
    Setting aside the "diarrhea" aspect of this technique,[...]

    In this context, it would be more of a logorrhea... and the pun writes itself.

  • JJ (unregistered) in reply to davee123
    davee123:
    It's better than bad, it's good!

    DaveE

    Not to mention that it also fits on your back.

  • (cs) in reply to Anonymous
    Anonymous:
    boog:
    I'd much rather take a few seconds to sprinkle some assert statements throughout the known problem area and let the error conditions surface on their own (but even that doesn't work in all situations).
    I see where you're coming from but surely this is the purpose of breakpoints?
    Yes, breakpoints can certainly save a lot of time when using a debugger. With asserts, however, I can have log messages that only appear when things aren't as they should be. It's certainly helpful when problems just jump out during execution and announce themselves.

    I should point out that conceivably you could configure a debugger to only break on a given breakpoint based on a given condition as well; this would be much like using an assert. I'm not sure if any modern debuggers have this feature though (that is, I haven't ever seen/used it myself).

  • (cs) in reply to TST
    TST:
    For a medical product, these logs are great because you can track everything that was done.

    Maybe I'm too anal, but I can't really see the WTF here. If the code passage is mission-critical I can understand the massive logging capabilities.

    TST

    Do not defend this fucking garbage. First of all, it doesn't log any exceptions. It doesn't even TRAP exceptions. What good is a log that only tracks success when all you will be searching for in it is failure anyway?

    Second, the place for such intense logging is not in the caller's code. It's in the called code. Those logging functions belonged in the methods of the drug and (puke) util classes if intensive logging was so important.

  • (cs) in reply to TST
    TST:
    For a medical product, these logs are great because you can track everything that was done.
    ...except that he keeps saying 'assigning' AFTER the line that tries to make the assignment, so the log is meaningless junk (did the line it refers to execute correctly or not?).

    He needs to change that to 'assigned' if it's AFTER the statement being logged, or else move the debug statement BEFORE the line being referred to.

    Christophe is obviously a useless tosser.

  • Abso (unregistered) in reply to boog
    boog:
    I should point out that conceivably you could configure a debugger to only break on a given breakpoint based on a given condition as well; this would be much like using an assert. I'm not sure if any modern debuggers have this feature though (that is, I haven't ever seen/used it myself).

    I don't know if any modern debuggers have this feature, because I'm stuck using Visual Studio 6.0. But it has conditional breakpoints, so I assume modern debuggers do too.

  • Anonymous (unregistered) in reply to boog
    boog:
    Anonymous:
    boog:
    I'd much rather take a few seconds to sprinkle some assert statements throughout the known problem area and let the error conditions surface on their own (but even that doesn't work in all situations).
    I see where you're coming from but surely this is the purpose of breakpoints?
    Yes, breakpoints can certainly save a lot of time when using a debugger. With asserts, however, I can have log messages that only appear when things aren't as they should be. It's certainly helpful when problems just jump out during execution and announce themselves.

    I should point out that conceivably you could configure a debugger to only break on a given breakpoint based on a given condition as well; this would be much like using an assert. I'm not sure if any modern debuggers have this feature though (that is, I haven't ever seen/used it myself).

    That's a very good point and asserts are definitely useful in this scenario. But you're also right about newer debuggers, certainly working under .NET (which is easier to work with from the debugger's point of view due all the metadata available in the assembly) it is quite common to be able to set conditional breakpoints. I think all .NET versions of Visual Studio support this. You can test variables in a conditional breakpoint so you have a fair degree of flexibility in defining your break logic.

  • Stefan (unregistered)

    That's why I love scripting languages.

    You can immediately do that thing more clever:

    function myEval($statement) { eval($statement); log($statement); }

    And then: myEval("brandNameDrugs = Utils.formatDrugList(dl.getDrugsByLabel(calculateBean.getDrugName()))"); myEval("majorClassifications = cl.getMajorClassifications(); ");

    You can even do: function myEval($statement) { print "// $statement"; }

    and you get perfectly commented code. Wheee. I have to use this for further programming!

  • (cs)

    Hey! It looks like someone took code out of one of my former employers!

    Except that all of those logfile.debug calls were actually System.out.println calls. Stuff like "Entering payrollBatch function" ... "Exiting payrollBatch function" and other niceties, and no "debug" flag either.

    Have fun.

  • Fedaykin (unregistered) in reply to qbolec
    qbolec:
    Actually it might be a good idea, to have logger plugged everywhere throughout the code as long as you have a nice way to turn it on/off, preferably at a module level granularity, when the interpreter is so slow that the impact is negligible anyway. In compiled languages you usually have preprocessor and thus can define log(x) to do nothing. But then you can not just turn it on/off on production. I can imagine some crazy way to force JITed languages to change implementation of log(x) on fly. Since I can, then probably it is already built in into .NET or something. But then again, I think it would be much better to have just a Trace mechanism built in into the interpreter/runtime environment/ or just a debugger, so that the developer doesn't have to echo each line of code to log(x).

    I found, that Math has a log function, but it doesn't do what I need, though.

    It's called aspect oriented programming -- a highly useful way to create runtime-dynamic code.

  • (cs) in reply to Stefan
    Stefan:
    function myEval($statement) { eval($statement); log($statement); }
    So that all of your code exists in evals and reproduces itself in the log file as it runs? You're a monster.

    Though I suppose if you really wanted to be thorough, it should say

      log('myEval("' . $statement . '");');
    
  • duis you agree with me? (unregistered) in reply to nitehawk
    nitehawk:
    Inigo Montoya:
    Since the department is governed by meritocracy, Christophe’s eight years makes him a “Senior” Developer and, therefore, correct.

    You keep using this word, I do not think it means what you think it means.

    http://dictionary.reference.com/browse/meritocracy

    I am willing to bet the "senior" devs at that company really do consider themselves a Meritocracy based on seniority alone without regard to talent.

    How about just merit?

  • Stefan (unregistered) in reply to boog

    The purpose of "myEval" (in contrast to "eval" itself) was to produce both: do the logging AND do the execution of the statement.

    Well as I see ... you meant the code inside myEval. You're right, it could say log('myEval("' . $statement . '");'); or did you mean log(myEval("' . $statement . '"));

    But then again. This would log the result of the statement. And as I read the original code only garbish is logged but not one useful value (of variables or anything).

    A monster? :-) Thanks for the compliment

  • P (unregistered) in reply to Jan
    Jan:
    I'm betting he once made a log method that tried to log something. I know I did ;-)
    That's OK, as long as you logged the stack overflow :-)
  • Jeremy Friesner (unregistered)

    Rather than cluttering up all the code with manual calls to log(), can something like this be supported at the language level?

    I'm imagining a language that keeps a streaming record of the program's run-state as it goes, and then you can later go back and do the "step-by-step debug" thing based not on the running program itself, but rather by replaying the log file.

    This is all assuming that you have plenty of disk space, and that performance isn't an issue, of course.

  • Gunslinger (unregistered)

    Sure, you'll just spend all your time debugging the logfile instead of the real code. Brilliant.

  • Anonymous (unregistered) in reply to Steve The Cynic

    Actually if you keep going North from anywhere, you can reach Canada. HINT: Ballistic missiles. Another HINT: Rotation.

  • keith (unregistered)

    The first time I was asked to implement a relatively straightforward process (every timer event, look for any zip files in target directory, open a zip file, find target data in a handful of possible text files for the database, move zip file to another archive directory) as a windows service, this is what my code looked like by the time I was done.

  • Darth Logger (unregistered)

    I have logged the code. Pray I don't log it any further.

  • (cs)

    I/0: 3 million transactions per second.

    User response: 8 minutes per transaction.

    Holding the disk storage contract for this company: Priceless.

  • DoWhat (unregistered) in reply to jim
    jim:
    Does anyone else just switch off when folks bang on about being a "Senior Developer" or "Dev Lead".?

    A guy I know has his current title on LinkedIn set as "Senior Lead Developer".

    Perhaps he makes hi-fi cables?

Leave a comment on “Log Everything”

Log In or post as a guest

Replying to comment #:

« Return to Article