See the writing on the wall...
-
always an empty catch block remind me open manhole's in road, i feel uncomfortable, doesn't know why
-
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program. The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here. And now method #3: - 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done. - A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices. - There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art. - The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know. Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}This is really an insult to the customer. Good that they will
CDP1802 wrote:
but does anybody know what a pflohneos, a finach or a fidel is?
Pfl ohne os, FileInfo nach, and a well known cuban dictator. :doh:
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
-
CDP1802 wrote:
but does anybody know what a pflohneos, a finach or a fidel is?
Pfl ohne os, FileInfo nach, and a well known cuban dictator. :doh:
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
You are right. As if DD's CCC had been turned into a convention for variable names :) Pf = Pfad (Path) l = ??? ohne = without os = operating system (Does that make any sense at all? Sounds just like 'Purple dog over the moon') fi = file info nach = after (after what, exactly)? I have marked the printout on the wall with color markers and also added some notes. At that place I also wrote 'Castro?' :) Ah, I got it! He's deleting files! fi = file (please note that he has galantly switched to English now) del = delete Here's another good one: danapfl dana = Dateiname (filename, first I thought he started to name things after his daughters) pf = Pfad (path) l = ??? What form of insanity is this and how is it treated?
At least artificial intelligence already is superior to natural stupidity
-
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program. The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here. And now method #3: - 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done. - A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices. - There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art. - The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know. Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}This is really an insult to the customer. Good that they will
The real horror is that mess should never have gone out the door and into the customer's hands. X| The customer needs to be given proper replacement ASAP and, of course the original programmer should not touch the replacement program. And tar and feathers is to good for the individual who wrote that mess. :wtf:
Just because the code works, it doesn't mean that it is good code.
-
The real horror is that mess should never have gone out the door and into the customer's hands. X| The customer needs to be given proper replacement ASAP and, of course the original programmer should not touch the replacement program. And tar and feathers is to good for the individual who wrote that mess. :wtf:
Just because the code works, it doesn't mean that it is good code.
That's what I have rcommended. It will not be sufficient to refactor a little, as my bosses hope. I have inherited all his projects from the last eight years. They all are such a mess. At least I'm honored that my bosses call me every time they think that all hope is lost :)
At least artificial intelligence already is superior to natural stupidity
-
You are right. As if DD's CCC had been turned into a convention for variable names :) Pf = Pfad (Path) l = ??? ohne = without os = operating system (Does that make any sense at all? Sounds just like 'Purple dog over the moon') fi = file info nach = after (after what, exactly)? I have marked the printout on the wall with color markers and also added some notes. At that place I also wrote 'Castro?' :) Ah, I got it! He's deleting files! fi = file (please note that he has galantly switched to English now) del = delete Here's another good one: danapfl dana = Dateiname (filename, first I thought he started to name things after his daughters) pf = Pfad (path) l = ??? What form of insanity is this and how is it treated?
At least artificial intelligence already is superior to natural stupidity
Is the nutcase an old git that learned programming when bytes were expensive? I'm thinking about classic unix folder names like 'USR' here. It could be fun decrypting this, but I think I would need to see more of the spaghetti monster to have a fair chance.
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
-
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program. The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here. And now method #3: - 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done. - A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices. - There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art. - The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know. Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}This is really an insult to the customer. Good that they will
-
Is the nutcase an old git that learned programming when bytes were expensive? I'm thinking about classic unix folder names like 'USR' here. It could be fun decrypting this, but I think I would need to see more of the spaghetti monster to have a fair chance.
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
He definitely is. Decoding his stuff is fun as long as the code gives you some hints to what is going on. Here he's messing around with files. By trying to kill running executables he also gives me the impression that this is supposed to be some kind of DIY deployment and updating mechanism. It really gets funny when it comes to updating the obviously running program itself. If you really want to have a challenge, then you should look at how he works with relational data. First everything is 'imported'. That means a lot of files are copied from somewhere in the network into a folder of the mobile device. The stuff is not XML or CSV, of which he usually is very fond. It's some creation of his own with fixed record and field lengths. And then he does not actually import anything. The program searches through those files to find and display data and changes are made to copies in another folder. Those changes are then sent off into the network again once the device is docked. That's what I call retro! A 'database' in the style of 1960 and a DIY DBMS that relies heavily on the file system and 'database files' which must be named after the primary keys of the content. All that in a mobile application that has been finished last week :)
At least artificial intelligence already is superior to natural stupidity
-
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program. The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here. And now method #3: - 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done. - A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices. - There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art. - The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know. Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}This is really an insult to the customer. Good that they will
CDP1802 wrote:
pflohneos, a finach or a fidel is?
That's quite elementary my dear Watson! pfl = pathfile ohne = without os = OS finach and fidel are variable containing FileInfo objects so the first part (fi) shoult be easy. nach = after (so be on the lookout for a variable like fivor) del = delete To fuck things really up for my cow-workers I'd have preferred variables named after whiskeys. Or better yet random text strings. ;P Cheers!
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
-
That's what I have rcommended. It will not be sufficient to refactor a little, as my bosses hope. I have inherited all his projects from the last eight years. They all are such a mess. At least I'm honored that my bosses call me every time they think that all hope is lost :)
At least artificial intelligence already is superior to natural stupidity
Well, it is good to feel needed, but that is a really nasty mess to have to clean up. X| Yes, bosses always want a quick, inexpensive fix, but I agree with you that there is no simple quick fix for this. :sigh:
Just because the code works, it doesn't mean that it is good code.
-
CDP1802 wrote:
pflohneos, a finach or a fidel is?
That's quite elementary my dear Watson! pfl = pathfile ohne = without os = OS finach and fidel are variable containing FileInfo objects so the first part (fi) shoult be easy. nach = after (so be on the lookout for a variable like fivor) del = delete To fuck things really up for my cow-workers I'd have preferred variables named after whiskeys. Or better yet random text strings. ;P Cheers!
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
-
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program. The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here. And now method #3: - 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done. - A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices. - There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art. - The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know. Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}This is really an insult to the customer. Good that they will
Did he move from VB and miss the
On Error Resume Nextstatement? X|Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program. The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here. And now method #3: - 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done. - A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices. - There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art. - The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know. Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}This is really an insult to the customer. Good that they will
:wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: 'Nuff said.
public class SysAdmin : Employee
{public override void DoWork(IWorkItem workItem) { if (workItem.User.Type == UserType.NoLearn){ throw new NoIWillNotFixYourComputerException(new Luser(workItem.User)); }else{ base.DoWork(workItem); } }}
-
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program. The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here. And now method #3: - 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done. - A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices. - There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art. - The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know. Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}This is really an insult to the customer. Good that they will
ok, this makes me question some of my code. I am pretty much self taught and don't have a lot of resources available other than online and within the help features. I comment quite a bit and try to use easy to understand variables (because otherwise a few months down the road when I need to add an update, I need to look back and know what I was doing). However, I do use empty catch blocks fairly often. Typically what I will do is set a variable to a default, then use a DB query to populate the variable with in a try/catch block (if the query returns no record it throws an exception). Then after the catch block, I'll check if the variable is the default value or not and execute code accordingly. Is there a better way or a standard practice that would be better? (see my sample snippet below, I use the prefix lowercase L to indicate the scope of variables that I reuse often)NOTE: This is a Windows Form app not a web site
int HCID = -1; try { lSQL = "Select HCID from HistoricalConversion where CoNum = '" + HCCoNum.Text + "'"; lAccessCmd.CommandText = lSQL; HCID = (int)lAccessCmd.ExecuteScalar(); } catch (Exception ex) {//Ignore error if no record exists } //Only run this code if there is an active historical conversion for this company if (HCID > 0) { //My code to run a stored Procedure if the record exists } -
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program. The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here. And now method #3: - 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done. - A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices. - There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art. - The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know. Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}This is really an insult to the customer. Good that they will
"Scotty. We need more power!" I canna give you any more Captain! The pflohneos is caught in the danapfl. I tried to cross-connect to the pflnamen, but the Konstanten is gonna blow any second if I do!"
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
ok, this makes me question some of my code. I am pretty much self taught and don't have a lot of resources available other than online and within the help features. I comment quite a bit and try to use easy to understand variables (because otherwise a few months down the road when I need to add an update, I need to look back and know what I was doing). However, I do use empty catch blocks fairly often. Typically what I will do is set a variable to a default, then use a DB query to populate the variable with in a try/catch block (if the query returns no record it throws an exception). Then after the catch block, I'll check if the variable is the default value or not and execute code accordingly. Is there a better way or a standard practice that would be better? (see my sample snippet below, I use the prefix lowercase L to indicate the scope of variables that I reuse often)NOTE: This is a Windows Form app not a web site
int HCID = -1; try { lSQL = "Select HCID from HistoricalConversion where CoNum = '" + HCCoNum.Text + "'"; lAccessCmd.CommandText = lSQL; HCID = (int)lAccessCmd.ExecuteScalar(); } catch (Exception ex) {//Ignore error if no record exists } //Only run this code if there is an active historical conversion for this company if (HCID > 0) { //My code to run a stored Procedure if the record exists }What you are doing there is controlling the program flow by catching the exception and doing nothing else with it. That's not very good because exception handling is very slow. A simple 'if' to check wether you have gotten any rows would suffice and your code would be faster and besides that easier to read and understand. ExecuteScalar() is a bit ugly because it returns an object if I remember right, so you must check for a null reference and after that use an adequate type cast. Besides that, just take exceptions by their name. They point out unexpected or unusual events. Don't use them for anything you expect. I usually take care of three cases: Some exceptions are avoidable. They are just cases which I did not consider in my code. This would be the NullReferenceException for example. Checking for null at the proper places is easy enough, but once in a while you simply forget it or did not expect a null value at that location. To prevent the program from terminating there should be a 'line of defense' where all exceptions are caught and at least are logged in some way, together with a stack trace and, if possible, any other relevant parameters. If you go through the trouble to read the log and then eliminating the causes of the exceptions, then you have a mechanism that's worth more than many unit tests and you will eventually get a very robust program. Then there are correctable exceptions. Obviously it's then a good idea to do whatever needs to be done to correct the problem in the catch block. Again, avoid the exception if you can. This is only for those cases you can't handle in any other way. And log it. When using your last option shows up too often in the log, it's time to consider improving the code. And then there are exceptions you cannot foresee, like calling a web service and getting a timeout because the server does not respond. Nothing much you can do about that except trying again later (or taking a look at the server if you can). Anyway, whatever you wanted to do is impossible for now and the exception then should be caught so that the following now futile steps are omitted.
At least artificial intelligence already is superior to natural stupidity
-
"Scotty. We need more power!" I canna give you any more Captain! The pflohneos is caught in the danapfl. I tried to cross-connect to the pflnamen, but the Konstanten is gonna blow any second if I do!"
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Did he move from VB and miss the
On Error Resume Nextstatement? X|Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
"Scotty. We need more power!" I canna give you any more Captain! The pflohneos is caught in the danapfl. I tried to cross-connect to the pflnamen, but the Konstanten is gonna blow any second if I do!"
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
LOL, this guy's had problems with deleting a file - so he's (badly) put some tests in. pfl = program file - as my best guess I think what was intended was to locate a file, check if it was readonly, make a copy in a different location, then delete the original -- all pretty straight forward. However rather the checking for readonly he toggles it, in his local storage (not on the file) - and he may toggle it, once or twice - so you can never know what state the file was. In the end Delete file - ignore any failures (including a file that doesn't exist). A perfect implementation of try {stuff} catch {nothing} finally {pretend it worked}
-
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program. The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here. And now method #3: - 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done. - A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices. - There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art. - The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know. Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}This is really an insult to the customer. Good that they will
Up against the wall! or is that too quick?
