- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
All too true - some companies have a youth only policy. They consider 40 to be too old to hire and they make 20-somethings seniors.
Admin
It does lead to some amusing situations though. One of my favorites is courtesy of Jon Stewart during the early parts of the financial crisis. One of the banks that had gone down put out a tub of water for people standing in line with a sign that said something like "For our customers, please have some 'water'". It cuts back to Stewart, who says "if I have some advice for the people in that line, it's don't drink the [air quotes] 'water'."
Admin
Logging for logging's sake is pointless. If you don't think so, just announce all your actions when you are enjoying your daily life: "I'm waking up" "I'm rolling over" "I'm turning off the alarm clock" "I'm getting out of bed" The list goes on. Do this enough, and the log file (your significant other) gets full and says ENOUGH. On the other hand, if you are a doctor and are attempting to diagnose a patient, this type of logging DOES have some merit ("I'm going to look into your eyes", "I'm going to do a prostrate examination"). You just need a switch to turn things off and on.
As was told to me in a programming class (over 40 years ago), the amount of information is inversely proportional to the probability of the action happening. So, logging the event of "Bill is sleeping at Laura's house" can have entirely different information content depending upon if Bill and Laura are married, married to each other, or not married at all. So, log files should have INFORMATION, not useless trivia.
Admin
You seem to imply that "logging" or "asserting" is superior to debugging (aka "step through debugging.) Yet adding logging code or asserts takes time. Time to add it, time to compile it. It is quicker to set up a few conditional breakpoints in the debugger and let it run than it is to add asserts and recompile the code. This is why "step through" debugging is superior. Of course there are times that logging is probably needed. Like if the program needs to run in Canada.
I'm not sure why you think it is so heinous that people open the debugger and step through the code to find the bug. Of course I'm not going to willy nilly step through the code either, that will take ages.
I think if peoples knee jerk reaction to a bug is to STEP THROUGH the code, then they are most likely good developers.
Admin
Do Canadians not have debuggers?
(I'm pretty sure I know what you meant but my interpretation is funnier.)
Admin
Admin
Admin
Our support department actually wants us to log everything. I went so far as to to extend the tool I wrote to run web services (they prefer it over Tomcat, for some strange reason) to log every parameter going into and coming out of a web service, and to write a library that logs all XML from SOAP requests and responses or faults into a database (so that you can use Oracle nifty XML processing to create a view that shows the XML as separate fields.
Developers are happy, because they don't have to write a bucket-load of logging statements, and support are happy because they get a bucket-load of logging.
Admin
log4net works pretty well for me
Admin
Nah, I'm pretty sure he does.
Admin
Yes logging everything is excessive - but c'mon guys - any of you who have never wished the program you're supporting has this option?
If it wasn't for performance problems I'd be all over logging every little detail.
Admin
That is pretty dumb. I don't thoroughly know what tools presumably Java 1.4 that he is using provides for debugging but for the languages I use I tend to use some kind of a call tracer at specific times when I need it to get the level of info we see here. I think when we start off we all do something a little similar here and there, but not so extreme and to not find out about tracers after having some considerable experience in a language is a great embarrassment. Java is always spitting out stack traces so I would be very surprised if there is not a faculty for a full trace. A flag perhaps?
In one language I turned it on by accident for everything and the HDD of a barely used server filled up on moments :/. Basically, it's not reasonable to have this sort of thing running all of the time even by accident, let alone deliberation. I also usually have a "log everything" function that attempts to log as much as possible about a request or instance. Of course, as I am sane, I only use these for emergencies and very sensitive areas. For example, if in certain parts of a payment related procedure, method or function something on the fringe of possibility happens that really shouldn't and may indicate a security breach with payment or a failure to properly process a successful transaction then the one time log every piece of global data and local data pertaining to the problem available routine kicks in. The reason there is obvious, if you have a problem in such an area debugging/fixing the code may not be sufficient as the bug may have left behind some data issues that must be fixed in a specific and proper fashion. A log will allow you to back track and make any necessary repairs. However, in most cases you only need a log of the input to re-run the requests.
The net result of the logging in the article will be so much data that it will be counter productive when it comes to locating issues.
Admin
Fair enough. log4j goes: FATAL ERROR WARN INFO DEBUG TRACE which is usually sufficient. Never had a real need to use FATAL, or rather, never been in a programming situation where such a bug gets triggered.
Admin
I fail to see the WTF with logging. If he is using something like log4net, then he can set (in the config file) the level of logging (ALL, DEBUG, INFO, ERROR) and get only what he needs when he needs it. As far as disk full error, log4net has rolling appenders and will reuse files after a certain size limit (you can specify this). Maybe he needs some error trapping, but for the most part I commend him on his level of effort. If more people would put logging levels into their code, then when a customer complains about something happening on a product that I have never even heard about before, yet I am expected to figure out what is wrong, then my discovery time would be greatly reduced. Its actually great coding, and it scares me that this community (usually so good at seeing crap) doesn't understand NOR use log4net and see that this is good.
Admin
Seconded. The approach is fine, it's just the specific implementation that's not so good. If you have a complex app whose behaviour depends on the vagaries of data over which you have limited control, it is often unfeasible to trap for every single error condition (because at a certain level you don't know what sort of errors are going to be in the files you are getting from your customers, and there is a limited window in which you are programming). So you write some fairly comprehensive logging messages, and when your customer complains that the app falls over, you enable the "Debug" logging level and get him to resubmit. The log message will tell you what the problem is.
The alternative is to use a symbolic debugger: get the customer to email you the file he's got a problem with, fire up a development version of the prod build the customer is running with, duplicate the prod environment, run the file through the application with the debugger on ... yeah. Nah.
As long as the logging messages are configured intelligently (i.e. the gave the job to me to do) then all will be well and the problem with the file will be easy to fix. But until the code mod to trap the error in question has been released to Production, the log message stays in place so the developer can see the problem when it happens again.
This may or may not be the optimal way to design systems but it works for us.
Admin
Except for those pesky edge cases, like Hawaii or Alaska.
Admin
A wtf, but it beats the alternative. I have seen some apps which, while in the strictest of sense they use a log file, in practice they open it, write "Opened log file on <date><time>" and nothing else.
I prefer this.
Admin
And if I ever find the moron who thought that was a good idea, there's a real risk of an increase in the local homicide level.
Admin
The problem is that Christophe doesn't log anything useful, though. He logs the flow of the method, which anyone can see by reading the code.
If he logged something like "Getting major classifications for " + brandNameDrugs (presuming that's a string), combined with excpetion handling/logging then the logs might actually be useful for someone.
"Hey, look every time we retrieve drug A, we get Exception X as few steps later."
What we're faced with in this scenario is, "Exception X happens sometimes after step S, but we don't know what the data was up to that point."
Admin
Classic indicator that someone a) doesn't know how to use a debugger or profiler.
I get after team members all the time for writing obligatory log.info("entering method foo()") and log.info("exiting method foo()").
I recently ripped out all entry/exit method logging and wrote a single AOP-driven logging class that could be enabled/disabled via a simple config which would log 1) method caller and line # 2) class/method being called 3) return back to caller and 4) total execution time for any method for the AOP's pointcut. I consider even this old-school since there are better tools out there that track this information then aggregate it into much more easy to visualize statistics.
I'm still regularly removing old-school entry/exit logging. Old habits die hard I guess.
Admin
Admin
It's okay though; you've constructed yourself a fantastic straw man, so you can just discuss with him.
Admin
Could be a series of Facebook status updates, too...
Admin
TRWTF on the other hand... is the number of people who didn't notice this as obvious log4j (or one of its derivatives like Log4perl). Any other logging system seems vastly inferior in comparison (no offense intended to anyone since writing your own logger is a rite of passage in software development).
Live and learn... then use log4*
Admin
That's nothing! A former coworker of mine added logging statements to the core logging methods. Nothing beats a
log(DEBUG, 'Writing new log message');
which crashed the app every time the logging system's logger was set to debug by getting a stack overflow.
Admin
That's not a meritocracy, it's a geritocracy
Admin
The real WTF here when I was working with this code is not necessarily the amount of logging because as many mentioned you can turn this on and off via a config file. Though I agree that an AOP approach would have been superior.
This post has been formatted with nice color to make it easier to read and see the difference between the log lines and the other lines. When actually working with this code in eclipse, every damn lines looks the same and you essentially have to cross your eyes to make heads or tails of what's really going on vs the logging.
Admin
Nothing wrong with this code other than the fact those log.debug()s should be at the start of a function and he could probably stand to kick all the log levels down a notch for the standard definition. And I have the feeling the former is an adaptation of the code so it can be posted on TDWTF. Also, no attempt is made to log arguments (which is probably the main reason you'd want to look at logs like this). Looking at the comments, performance is almost certainly not an issue in this portion of the code. If I had to pick a real WTF, it'd be manually putting in each call (but if it's in only a few places, it might be better to do it manually for the sake of the next point).
This might LOOK excessive, but when you pass the code on to someone else they will appreciate having a record of a statement you considered useful at some point. If they say "no way in hell I'll ever use this", they can delete it. Then, when an issue pops up where that statement would've been useful they'll have a better chance of remembering "gee, that's what it was for, better start looking in X, Y, Z for the problem then" compared to you never putting that statement in at all.
Any good log utility will let you filter out arbitrary levels. In the error case, I assume some sort of extremely intrusive error will pop up, though it's good practice to log it anyways.
Admin
20101412:135905.0192 [sysinfo] Now starting comment I call bullsh_@&$*) ++Stack overflow, trace c000000024316140 Thread(8748, tdwtf, c0000000242e2958, 3) File: rsdebug.c Line: 1030
Admin
If the code is running off site, often the log file is all you have to debug with. In that situation, a completely detailed log file might be useful. Just saying.
Admin
I'd like you to ponder on that last statement. Logging and using breakpoints provide fundamentally different views of your data: pausing execution at a breakpoint gives you a snapshot of the current state of the program versus logging, which gives you a progression of states.
I believe the latter to be a much more helpful technique, given the following conditions:
Log files are superior to debugging because they are persistable and searchable.
The benefits of being persistable should be clear to you. The customer can send you the log file (possibly automated by your application) and you can attach it to a help support ticket, send it by e-mail, etc.
However, the (usually lacking) major benefit comes from good structure making log files searchable. Given a good structure, you can filter aposteriori the debug level, the sub-set of relevant functions (by module, for instance), etc. This is specially helpful in debugging some difficult to reproduce errors related to timing (think multi-threaded here). There are obviously additional benefits to good log files, such as:
-> applying more flexible conditions than those kindly produced by the debugger vendor's imagination -> you might not have access to a debugger (for various reasons, including no access to the client's machine)
Here are some examples of filtering I've come up with out of the top of my head:
-> show me invocations of function foo(), but only when invoked through some (possibly indirect) call by bar -> show me invocations the last invocation of foo() prior to call to meh()
Now, I'm assuming that your original statement is basically rooted in the fact that designing such logging facilities is a major engineering problem in itself, possibly as hard as your current project. Someone would argue that so is engineering a debugger, but you've already got one of those bundled with your IDE. Thus, any employee with the fantastic idea of designing such a loggin system will be accused of attempted yak shaving and will be explained that using a debugger has a higher perceivable financial benefit than a logging system.
Admin
FTFY
Haven't read other comments that were logged, but I would be surprised if I'm the first to debug this problem in the article.
Admin
I don't entirely disagree with Christophe. It needs to be switchable though. I wish more languages or environments supported automatic logging that wasn't totally pox.
Admin
The main problem I see is that he's not logging any of the variables. The only use for this much logging would be to see on which line code stopped running, after which you could put more detailed logging around that point. If the code's not breaking during this section, then the logging is useless, even as a record of what the program did because the log will just repeat the same lines again and again.
Admin
Yo Dawg! I heard you liked debugging, so I loaded your debugger in a debugger so you can debug while you debug.
Admin
That's still better than the opposite. True story - I once worked in a department linked to various other departments and our applications depended on various other applications built and maintained by these various other departments. We launched a new release after thorough testing, that relied on one such other application. The next morning, our application had failed miserably, and we traced the failure to the other application. Our project head asked the other department, "Can you look in your logs to see what happened?" Mind you, this was in Production... and they responded, "Oh, well, actually no - we only log successes!" FACE PLANT INTO DESK
Admin
He should program in C or C++ and then can use a macro to log every line and macros allow you to stringify.
Admin
void logger::debug(const std::string& text) { this->debug("Writing to log: " + text); file_ << text; }
Uh oh....
Admin
Im in hawaii and getting the same results...
Admin
A debugger is the root of all evil.
Admin
Why you need FATAL level, if you have out of memory problem, this throws FATAL error.
Admin
Admin
For critical background jobs I do just the same thing. I use log4net though, so I could simply uppen the level of an appender if I don't want all the debug stuff logged... Also I ommit the comments when working this way, otherwise the comments just repeat the log statement like in the example.
Admin
It doesn't...it has absolutely nothing to do with time nor does it have anything to do with seniority in a company. Not sure whether the logging was really "Christophe's" idea or maybe this guy's...you know, the old, "I have a friend who..." bit.
Admin
This looks almost exactly like the type of logging I used to do on the very first code I wrote.
Admin
CORE::log. HTH. HAND.
Admin
Not only can some modern debuggers do conditional breakpoints, but you can also add conditionals just for the purpose of breakpoints if your debugger does not.
I find this far more useful than an assert, because you can then inspect any part of the program's current state.
Admin
This reminds me of when I started at my second IT job. My initial position was "Senior Systems Administrator". As my prior job was as a programmer, I felt that 'senior' was fairly silly.
Then I met a Junior Systems Administrator who'd been working for them for 20 years, and realized I was working for a company that sometimes got their titles right.
(When someone just out of college a couple of years with no experience with your server's OS can debug your system in 30 minutes with sufficient accuracy to pinpoint the exact line in your config file that's wrong (not just the contents of the line, but the line number), without officially having access to the box, and you do have full access and cannot debug the system's problem despite having weeks to do it during which this issue is your top priority and despite 5 years experience administrating this particular server, you probably should not be its only administrator - even if it's just an ancillary service having problems.)
Admin
TRWTF is that both "Christophe" and "erro" are missing a trailing "r".