Happy debugging!
-
While debugging some problems in an automated console application I ran into this:
try {
//some code
} 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 {
/\*Overriden the GetType class method so that it returns a different class name than it should, it no longer returns the name of the class it's in\*/ private string GetType() { return "ISyncService"; } private int methodThatThrewError() { //some code try { //some other code } catch(Exception e) { /\*We log exceptions by class name, method where it occurred and exception message, plus optionally stack trace\*/ Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", ""); /\*Also make sure we're always successful\*/ 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.
I suppose there is the possibility that a potentially exception throwing routine simply must be called in a destructor, and that logging or otherwise reporting the exception is not acceptable because allocating the necessary resources is potentailly unsafe, in which case your colleagues code would be quite acceptable. One might find a similar argument in a C++ library with an extern "C" interface. Reporting or logging errors isn't always an option. Sometimes you just have to use other methods. Besides, further compounding the problem by obfuscating the errors is a suspect solution. Did you push your changes?
-
I suppose there is the possibility that a potentially exception throwing routine simply must be called in a destructor, and that logging or otherwise reporting the exception is not acceptable because allocating the necessary resources is potentailly unsafe, in which case your colleagues code would be quite acceptable. One might find a similar argument in a C++ library with an extern "C" interface. Reporting or logging errors isn't always an option. Sometimes you just have to use other methods. Besides, further compounding the problem by obfuscating the errors is a suspect solution. Did you push your changes?
Time to point out that this is C# code.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
While debugging some problems in an automated console application I ran into this:
try {
//some code
} 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 {
/\*Overriden the GetType class method so that it returns a different class name than it should, it no longer returns the name of the class it's in\*/ private string GetType() { return "ISyncService"; } private int methodThatThrewError() { //some code try { //some other code } catch(Exception e) { /\*We log exceptions by class name, method where it occurred and exception message, plus optionally stack trace\*/ Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", ""); /\*Also make sure we're always successful\*/ 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.
I'd like to go a bit further, as a rule of thumb everytime time you go into the more general exception (as in your case) you MUST quit the application, of course you can log it but it's mandatory to quit if your program stayed in a compromised situation, otherwise you are able to inform your users about the problem (which should be very specific or maybe catch a more specific exception and solve it). Many programmers do what your colleague did because they think it's not professional to quit that abruptly, wrong!, it's not professional not to accept the problem.
Carlos Alberto
-
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 = ;
}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 :-D , 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.
-
While debugging some problems in an automated console application I ran into this:
try {
//some code
} 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 {
/\*Overriden the GetType class method so that it returns a different class name than it should, it no longer returns the name of the class it's in\*/ private string GetType() { return "ISyncService"; } private int methodThatThrewError() { //some code try { //some other code } catch(Exception e) { /\*We log exceptions by class name, method where it occurred and exception message, plus optionally stack trace\*/ Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", ""); /\*Also make sure we're always successful\*/ 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.
Hah! You think that's bad?! Some time ago, I inherited some code which had about 70 data classes, each containing three or four methods along the lines of:
public override void CreateEntity()
{
try
{
// blah, blah, blah...base.\_database.ExecuteNonQuery(storedProcCommandWrapper); int parameterValue = (int) storedProcCommandWrapper.GetParameterValue("@RETURN\_VALUE"); if (parameterValue == 0) { throw new Exception("Create failed."); } // blah, blah...}
catch (Exception exception)
{
exception.Message.ToString(); // Why?!
throw new Exception("Exception occured", exception);
// OK, let's not bother checking the spelling of the message either!
}
}Needless to say, all of the code which called these methods looked like:
try
{
customer.CreateEntity();
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}No logging. No access to the inner exception. No way to diagnose why one button was displaying the really helpful "Exception occured" error every time the user clicked it. X|
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
While debugging some problems in an automated console application I ran into this:
try {
//some code
} 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 {
/\*Overriden the GetType class method so that it returns a different class name than it should, it no longer returns the name of the class it's in\*/ private string GetType() { return "ISyncService"; } private int methodThatThrewError() { //some code try { //some other code } catch(Exception e) { /\*We log exceptions by class name, method where it occurred and exception message, plus optionally stack trace\*/ Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", ""); /\*Also make sure we're always successful\*/ 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.
If this is to teach him lesson then I agree with you, considering the fun. :-D But for deployment, it may cause serious problem.
-
While debugging some problems in an automated console application I ran into this:
try {
//some code
} 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 {
/\*Overriden the GetType class method so that it returns a different class name than it should, it no longer returns the name of the class it's in\*/ private string GetType() { return "ISyncService"; } private int methodThatThrewError() { //some code try { //some other code } catch(Exception e) { /\*We log exceptions by class name, method where it occurred and exception message, plus optionally stack trace\*/ Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", ""); /\*Also make sure we're always successful\*/ 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.
Once, as a prank, a guy put an ASP.NET error message as data in the database (with the HTML formatting). Then he told another developer to look into a problem where in a HTML table on of the cells would display the ASP error message. :-\
-
While debugging some problems in an automated console application I ran into this:
try {
//some code
} 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 {
/\*Overriden the GetType class method so that it returns a different class name than it should, it no longer returns the name of the class it's in\*/ private string GetType() { return "ISyncService"; } private int methodThatThrewError() { //some code try { //some other code } catch(Exception e) { /\*We log exceptions by class name, method where it occurred and exception message, plus optionally stack trace\*/ Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", ""); /\*Also make sure we're always successful\*/ 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.
-
While debugging some problems in an automated console application I ran into this:
try {
//some code
} 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 {
/\*Overriden the GetType class method so that it returns a different class name than it should, it no longer returns the name of the class it's in\*/ private string GetType() { return "ISyncService"; } private int methodThatThrewError() { //some code try { //some other code } catch(Exception e) { /\*We log exceptions by class name, method where it occurred and exception message, plus optionally stack trace\*/ Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", ""); /\*Also make sure we're always successful\*/ 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.
FAIL. Sorry to be a party pooper, but your evil intentions would not be fulfilled by that. You haven't overridden the GetType method. You've hidden it. And that means the compiler will only bind to the implementation if invoked on a reference of type TheClass. And it's unlikely anyone would call GetType on the thing if it's already declared to be TheClass (although the run-time type of course could be a descendant). So, since GetType isn't virtual it'd still return "TheClass" and your colleague would go to the code and see that you've attempted to fool him. (If you guys have decent source control anyway.) I do sympathize with your sentiments though. But frankly it is often the project managers who are at fault, because rather than foster a culture where mistakes are openly discussed, not for the purpose of punishment but for education, they tend to reward people who "are positive". In my experience that's often people who aren't competent enough to see the myriad things that are usually F-ed up in... well, any codebase I've come across.
-
While debugging some problems in an automated console application I ran into this:
try {
//some code
} 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 {
/\*Overriden the GetType class method so that it returns a different class name than it should, it no longer returns the name of the class it's in\*/ private string GetType() { return "ISyncService"; } private int methodThatThrewError() { //some code try { //some other code } catch(Exception e) { /\*We log exceptions by class name, method where it occurred and exception message, plus optionally stack trace\*/ Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", ""); /\*Also make sure we're always successful\*/ 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.
Andrei Straut wrote:
Yes, I'm a devious SOB, but hey, if they don't care, why should I?
If you didnt, then you and that person do not have/make/create any difference. Its just like watching a crime happening and ignoring it than atleast reporting.
-
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.
-
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.
-
Time to point out that this is C# code.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
While debugging some problems in an automated console application I ran into this:
try {
//some code
} 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 {
/\*Overriden the GetType class method so that it returns a different class name than it should, it no longer returns the name of the class it's in\*/ private string GetType() { return "ISyncService"; } private int methodThatThrewError() { //some code try { //some other code } catch(Exception e) { /\*We log exceptions by class name, method where it occurred and exception message, plus optionally stack trace\*/ Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", ""); /\*Also make sure we're always successful\*/ 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.
