- 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
Log.commentsStart("first")
Admin
Log.commentEnd(frist")
Admin
It stil has the try-cache comment...
Admin
and a wrong "it's"
Admin
looks like he was way ahead on Meltdown und Spectre with the processor when processing a try-cache statement ... ;)
Admin
... so exactly why do you need to override it in the first place? It just calls the base version.
Admin
Given the updated version literally only calls the base method, why not just delete the override?
Admin
Looks like a bunch of "cry {} natch {}" :)
Admin
What's wrong with logging function entry/exit? Provided it's done in a smart way, of course, in which it can be enabled/disabled for the smallest reasonable subset of code that you wish to debug, such logging can prove invaluable for tracing the code flow through a complex system. Especially when investigating timing-related problems where step-by-step debugging may not be feasible... such as in a multithreaded environment.
Admin
Elegant desgin. But "Make sure we loop only once" is a wrong comment. It loops 0 times.
Admin
Don't throw stones if you live in a glass house.
Admin
I love the fact he not only sets bLoop to false but also uses a break. He really wants to be sure the loop only gets executed once!
I get the idea of easily disabling an entire block of code (not that I would do it like this), but then why not just write
if (true) { .. }Admin
I mean, at least do it with aspects or something
Admin
No WTF there. Just another dev paid by LOC.
Admin
But it does that without the Log.LogEntry()-call, which (I guess) does nothing.
Admin
Clearly the man was someone paid by the keystroke and not someone that was encouraged to write clean, compact code.
Admin
I'm pretty sure that Log.methodEntry(String) and Log.methodExit(String) just write a predefined text with the given String to a log somewhere and don't produce objects and Log-Sections based on the given String and calling Method.
Admin
I know such a person. But instead of catching Exceptions we had an
On Error Goto [methodname]_Err
And every Method ended with
[methodname]_End: Exit Function ' **************************************** Error Handling ******************************************* [methodname]_Err: DisplayError("some explicit message stuff written in the same pattern every f..ing time") End Function
It was the person I worked for in a small software company. I quitted that job as soon as I had found another one.
Admin
i whiled away my time reading this. Thanks for the post
Admin
I mean, if you're swallowing exceptions, isn't it a try-cache block?
Admin
I don't see the connection between The Man's horrid coding and the two ways of accumulating experience. Anon does not know what kind of code The Man wrote when he had no experience. Perhaps every single atrocity The man inflicts on his code base is the result of a painful but instructive experience.
Admin
Hush! You're not supposed to mention, or even just notice, me.
Admin
Farhad, is that you, "The Man", or you're the disciple of "The Man"?
Admin
The style looks like a very highly refined version of some bad ideas, and especially bad ideas that have persisted because he's never tried them as the new guy.
Admin
Right, and the smart thing is generally the easiest and simplest. And the simplest way to debug any problem is always going to be to debug that problem, and not hypothetical problems. That would mean writing log statements suited to the problem, where you think the problem exists, rather than adding crap you don't use to every method in the entire code base.
Or, you know, just use a profiler.
Admin
My personal favorite on this is the redundancy in the single-pass while loop pattern. It has the boolean guard variable 'flag' that will prevent the loop from executing a second time, and it also has a break statement at the end of the block. For when you have to be doubly sure that the while loop construct never does its job.
Admin
There's the hope that a decent compiler will get rid of the whole loop variable nonsense without generating any code.
Admin
If you're logging where you think the problem exists, it means there's a problem.
A problem you weren't logging.
A problem that you can't travel back in time to reproduce.
So you're really not doing any better than the Entry/Exit logging.
Instead, you should have said, when you were writing whatever it is, "Hey this is a thing that shouldn't happen, so I should wrap it in a try/catch and log the problem close to the source, where I'll have context, because experience has taught all of us that whenever something should never happen in code, it will happen constantly, and be impossible to debug since I think it can't happen!"
Admin
The comments on the new function don't match the content of the function at all. The next developer who will read the code will not know what the comment is about. It should have been his commit message
Admin
Obviously you never wrote Software other than for yourself. You can't add logging to the software after it has been delivered to your customers. No one is going to pay you for the effort of creating a special debugging version of your software for every case where a customer has a problem. No customer is going to install a debug version of the software just to get a log file for you.
And you very much do not understand what "timing problems" are. Not "performance problems" - for those you use a profiler. "Timing problems" means: Race conditions and similar problems, where certain bugs will not happen all the time, but only if a certain "timing" happens. For example when one thread is slower than usually and a required barrier is missing, a second thread fails to work correctly, because it wrongly assumes the first thread already did provide a required precondition.
Admin
I like the re-implementation of IF using WHILE break;
Admin
I wondering if this is even true, why would someone rape code that hard..
Admin
"The intent was to keep the application from ever crashing. There was no concept of rolling the error up to a place where it could be properly handled."
Tell me one time that you ever saw anybody actually do this and not simply hide the error behind "oops, something happened, try again."
It's much smarter, in practice, to check the return value of every function call and throw exceptions up starting at the point of failure. Done properly, you get a stack of "call to function X failed" with the actual error, often times even in English, that started this at the bottom. At the recognized starting points, typically your UI (window or page), this list is parsed for display and not turned into an outright crash with another throw. The issue, as always, is competent developers. They need to operate consistently, check return values, provide useful error messages, and break down problems into small parts so you're not poring over a 40-page function struggling to determine which call to some function actually failed. If you do this, you don't even need a debugger; if business logic has you stepping through breakpoints, you, your team, or your architect(s) have screwed up.
People like to say no software is good or all software has bugs. That's because they write garbage and make excuses like "all software has bugs."
Admin
Came here to say the same. TRWTF isn't in entry/exit logging, it's in (apparently) having just one log level. Log entry/exit at the least important level, and activate them only when needed and/or on development environments, job done.
Admin
Whats wrong with entry and exit logging? Well other than adding a shit-ton of hay on top of the needle, in a multi-threaded environment you would get useless and overlapping logs. Better to gather some context, and log on an error, which would never happen since all errors are swallowed anyway.
Admin
Relying on call stacks in error message dialogs rarely works sufficiently in practice. Obfuscation usually hides most of the useful details on what functions were called, and users rarely take screenshots of the error message and just complain that it failed. Once they dismiss it, it's gone.
Admin
I mean all software does have bugs, but it's the developer's decision whether they're clever little bugs that are only seen once in a blue moon, or abjectly stupid bugs in every method that cause a constant rain of support calls, and reinforce users' perception that computers exist only to frustrate us.
Admin
There are ways to make entry and exit logging work in a multithreaded environment, such as stamping the thread ID (or session ID for web apps) into the log message prefix. But it's always verbose as heck and something you only do if you must and at very fine debugging levels. (If you have AOP available, it's a reasonably good use for it since it lets you keep all that crap out of the source…)
Admin
ugh.... I almost feel this shouldn't be real...
Admin
ugh.... I almost feel this shouldn't be real...
Admin
Because way back when, Visual Basic would sometimes leak objects if they weren't set to Nothing before the function returned.
Admin
AOP. That kind of logging is a cross-cutting concern that could easily be encapsulated as an Advice, thus avoiding the extra code and its boiler-plate