|
I'd add logging of the original string if TryParse returns false.
Maybe it's indicative of a problem with callers if they pass a non-parseable string (somebody sends in "eight" instead of "8"), where you can continue without problems, but you want to research the application and see who's passing the offending strings.
|
|
|
|
|
Maybe you are right, but the input is a machine-generated log file of a medical instrument, so there is no chance for a user to input wrong data. Further, it is possible that a line of the log file contains no ID, so it isn't very useful to search for any descriptions of the ID (which the program does when a Id was found)...
I am not french.
|
|
|
|
|
Hmm.. i see such silly mistakes being done all the time by fellow colleagues. This is due to the fact that, folks think they are good at their code and langauge grip. Inact, they should know that the art of programming has to be tinkered every day, then only such mistakes can be avoided. But hey, its the big EGO :x
|
|
|
|
|
While debugging some problems in an automated console application I ran into this:
try {
} catch(Exception e) {}
I had lost some 15 minutes tracking this problem (product information not updated in the DB and error log came up empty), and you can imagine I got really angry seeing this stuff. I take it seriously to logging errors, even non-fatal ones.
While I can sometimes understand catching Exception, why the hell didn't the guy at least log it?
And then...I had a flash of inspiration. So I did the most devious thing I could think of at the time. Knowing that the colleague that wrote this code rarely uses the debugger (he usually debugs the code by placing Console.Outs, builds the application and runs it), I changed that class and the try-catch into the following (comments are mine, and not present in the code):
class TheClass {
private string GetType() {
return "ISyncService";
}
private int methodThatThrewError() {
try {
} catch(Exception e) {
Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", "");
return successCode;
}
return successCode;
}
}
Basically, when this exception occurs, it will appear that it happened in a whole different class (and an interface for that matter).
That should teach them to log stuff properly, or use the debugger.
Yes, I'm a devious SOB, but hey, if they don't care, why should I?
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
That's just evil. And I like it. +5!
I think computer viruses should count as life. I think it says something about human nature that the only form of life we have created so far is purely destructive. We've created life in our own image.
Stephen Hawking
|
|
|
|
|
Why don't you speak to this colleague ?
Until today, to speak is the best way to explain your point, and to be understood.
You might even learn something doing so ...
To play more stupid than the stupid is a sure way to failure, for both you and him.
gzo
|
|
|
|
|
I did, and nothing changed. Although this colleague is a friend, and one of my best actually, he did nothing on this despite my repeated requests.
Patrice STOESSEL wrote: To play more stupid than the stupid is a sure way to failure, for both you and him.
I'm not sure whether to take this as offensive or not.
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
Take as a advice.
your line of thinking is among the lines of:
"oh, they started a war and destroyed themselves, we will teach them a lesson by starting another war!"
makes sense to you?
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
Sentenryu wrote: "oh, they started a war and destroyed themselves, we will teach them a lesson by starting another war!"
makes sense to you?
TBH, actually it does, but I may just have a sick mind  . As I said to Patrice, I repeatedly asked for errors to be logged properly, with no result, so this one was somewhat of a last resort, and half-jokingly made.
I'm the one working on the code 80% of the time and writing 80% of it, and I don't want to have to track errors that are hidden.
I may just be a code Nazi, but I've had to work on legacy projects that had no documentation/code formatting/error handling at all, and it's not pleasant.
I try my best to write readable and understandable code, for me as well for those that will come later (as is exactly the case, tomorrow is my last day at the job), and I only ask the same for my colleagues. I can understand when it's not possible for various reasons, but when it does become a habit I take it seriously.
There is also the argument that I could take it to management, but I didn't want to do that, as I've known this chap for quite a while (went to college together, and then we've become work mates too for the last couple of years) and he's quite a nice guy. My gesture was not made with bad or harmful intentions, but more like a tongue-in-cheek of what can happen when you don't properly trace your stuff.
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
I wonder how long it will be before your replacement posts this code in "code horrors"...
Seriously, if your intention is to "make a point" then it might have been more appropriate to log it with a type of "HowTheHellWouldIKnow" and a message of "So There IS a point to logging after all" rather than deliberately misleading the next poor guy who has to unravel this. If anything, writing incorrect data to the log is just going to make him even LESS likely to log errors, because the log won't be reliable.
I understand your frustration (believe me, I understand!) but I'm not convinced that this was the wisest approach. In the worst case, if there's a serious bug and it takes 5 times as long to debug as it should because of the misleading stuff in the log, your company may lose revenue / customers / credibility and ALL your ex-colleagues may suffer. Suggest you email your pal a note pointing out what you've done... 
|
|
|
|
|
DerekTP123 wrote: Suggest you email your pal a note pointing out what you've done...
No, I think I'll tell him directly.
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
I agree with you, but some people are just bricks.
I used to work with this programmer whose opinion was that if his program GPF'd it was the user's fault.
All I could do was make his life hell by finding out how fast I could crash his program and then give him a step by step set of instructions on how to reproduce it. He eventually quit and I'm sure he's doing the same at a new location.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Together as a team you failed! so your employer!
...
|
|
|
|
|
If your coworker never bothers to log exceptions, why would he start looking at the log file now that you're sending inaccurate data to it?
|
|
|
|
|
He'll have to at some point. Suppliers change their feed formats quite often, and something will break eventually, as was the case with the problem I was tracing (one of them changed the positions of some info fields in the feed - a CSV file without any kind of headers).
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
So you're playing these games with your coworker with live, production software?
|
|
|
|
|
I'm sorry, but I fail to see the funny side. How is the person who takes over from the pair of you going to think when he finds this code? I expect we'll see it posted here again as an example of a code fail. Yes, the original code was wrong, but you have just made the situation 10 times worse, and potentially stored up a huge problem for your employer in the process.
The fact that you did this deliberately is shocking.
|
|
|
|
|
Pete O'Hanlon wrote: How is the person who takes over from the pair of you going to think when he finds this code?
He won't. It's fixed and my colleague announced. Actually he did find it somewhat funny.
Pete O'Hanlon wrote: Yes, the original code was wrong, but you have just made the situation 10 times worse, and potentially stored up a huge problem for your employer in the process
I fail to see how I created a huge problem. I did not change the data or interact with it in any way (except fixing what came wrong), I logged something badly instead of not logging it at all, and whoever used the VS debugger would notice it in a flash.
Pete O'Hanlon wrote: The fact that you did this deliberately is shocking.
Although I do acknowledge it was uninspired and totally unprofessional (I try to take myself seriously, as well as others, and here I was wrong), shocking no, I don't think so.
Again, I was wrong for this, and thanks to the CP community for pointing it out.
EDIT: Should I delete the thread, or leave it as is?
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
Leave it. Hopefully others can learn from it. Sometimes a quiet word is the right solution to a problem.
|
|
|
|
|
I have to agree with Pete. The feeling I get reading this thread is that your coworker wrote some bad code out of stupidity/stubbornness/inexperience and you countered that with malice.
Shocking doesn't begin to describe it to me. If that code got checked into the repository, you're fired.
Sorry to be so harsh, but this is a completely inappropriate way to handle the situation.
I have to say, I am in total agreement with you on your notion that logging every caught exception is the proper way to go. Even if your code can continue on properly, it's good to log that. To give a trivial example:
int num = 0;
try {
num = Convert.ToInt32(string);
} catch (FormatException e)
Log.Info("Couldn't convert " + string + " to int, using default");
num = <some setting from config>;
}
Of course, this is trivial, but you get the idea.
|
|
|
|
|
The problem with the simple example is that the catch could blow up throwing you out of your process completely. (The passed "string" is null. The Info function should throw because it was passed null...) What if the string is a few thousand characters? I wouldn't use data passed to the process in the message either.
Probably something like
Log.Info("Using default value for \"ConvertToInt\" process because of msg:" + e.Message);That isolates what caused the problem from the log process. And may actually tell the user what went wrong and why.
Your user guide would, of course  , tell the user what ConvertToInt does, how they might encounter it and what the default value would be.
I can certainly understand the orig. poster's frustration, he has a friend who's being thick-headed in one area. He used a humorous way to illistrate that no message could be nearly as damaging as intentionally sending a misleading message.
|
|
|
|
|
1. A programming language that would even let you do this is broken. I feel so unclean just having read this.
2. Type that into the codebase, and it's only a matter of time before you are the victim; either of forgetting to take it out, or having it used against you.
3. Pranks. Oy! I've worked in organizations where pranks got to be the accepted norm. They are sick and unprofessional organizations. Generally what happens is somebody goes too far. Maybe there is an injury, or a customer gets pranked by accident. Then there is a short, grim meeting where your boss or your division manager or somebody from Personnel lays it on the line saying, "Next prank gets you fired."
A better approach is to make the dumb behavior (not logging) an issue with your colleague, and if he doesn't make an attempt to improve, with your team or your manager. Because your colleague can certainly make the pranking an issue with your manager. Then he will have the moral high ground and you will lose traction on getting the undesirable behavior fixed. If you act unprofessionally because your teammate did, that fixes nothing.
|
|
|
|
|
Quote: "A programming language that would even let you do this is broken." -SeattleC++
.
Have you ever actually used C++, at all? I'm guessing no, otherwise you'd realize that it's quite capable of doing truly horrible things...
|
|
|
|
|
Joe_Dert wrote: Have you ever actually used C++, at all? I'm guessing no, otherwise you'd realize that it's quite capable of doing truly horrible things...
This is hardly to the point. And yeah, I've used C++. Since you were in middle school, I'm guessing.
It may well be true that it's a poor workman who blames his tools. But it's also true that it's a deranged colleague who thinks up ways to deliberately damage shared tools and then checks their perverse thoughts in. And then brags about it.
|
|
|
|
|
You're dodging the issue, he did something devious, yes, but, that wasn't my point.
Pay attention, you said that any language that allowed him to do what he did was broken, to which I responded(more or less), that C++ is far worse in that regard.
(ie: By your reasoning, C++ is broken, because it has many mechanisms which can be abused to do devious things.)
Furthermore, I'd suggest that you take some of your "assumed" wisdom of years, and at least try act the part of the wise older man if you want to play the: "I've been coding since you were in diapers" card.
Let's be frank, I had quoted you, so, assuming you speak English, you know what I meant, so, either you're a troll, illiterate, or perhaps just senile?
Best case scenario, I'm willing to conclude there was some sort of misunderstanding.
modified 22-Oct-12 2:44am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
