|
Duncan Edwards Jones wrote: Is it called "Program.exe"?
No, but thanks. I'll have to try that some time. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
Maybe it's the new iOS feature that deletes apps when you are running low on space? 
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That doesn't sound familiar, but I've had Stored Procedures disappear from SQL Server before.
|
|
|
|
|
Beacause it will surely work a 100% the second time 
SqlCommand cmd = new SqlCommand(query,conn);
SqlDataReader reader = null;
try
{
reader = cmd.ExecuteReader();
}
catch(InvalidOperationException e)
{
cmd = new SqlCommand(query,conn);
reader = cmd.ExecuteReader();
}
|
|
|
|
|
Really should be in a loop 42 times! 42 times always work out nicely! 
|
|
|
|
|
What about a recursive method that runs until it works? That should "fix it"
|
|
|
|
|
Don't forget to put in an
Thread.Sleep(500) to give the database connection a chance to recover from the failure state.
|
|
|
|
|
I've seen and written code like that.
One time there was a bug in a big ass Oracle procedure that made it return no records on the first try, but did the right thing after that (don't know what it was, we're talking about 100's of lines of Oracle code, a horror in its own right!).
Once had an issue with a rather unstable connection that often made it fail the first time.
Same thing for timeouts. Timeout on first try, instant result on the second try.
While retrying isn't really a solution it may get the desired result with very few trouble.
Especially useful when it has to work NOW and the real issue is not so easy to fix (or not yours to fix).
|
|
|
|
|
Besides the problem of repeating the same thing inside a catch, the other big problem is that the second time also throws an error sometimes. The "easy" fix was to put another try and catch block inside that catch, until I could understand what the hell was happening in that code
|
|
|
|
|
This calls for a do-while! xD
bool failure = true;
do
{
try
{
failure = false;
}
catch(Exception e)
{
failure = true;
}
} while (failure);
|
|
|
|
|
See Einstein's definition of insanity.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
I don't think this counts, because they are EXPECTING different results once they have an exception...
|
|
|
|
|
Einstein never used a (modern) computer.
|
|
|
|
|
Two minor points here:
1. Einstein was a physicist, not a psychologist or psychiatrist. Being a genius in one field does not necessarily qualify you to speak with authority in any other.
2. He never said it anyway. At least he seems to have been smart enough to know (1).
(Quora[^])
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I'm assuming the programmer assumed the first try could go wrong and handles exceptions in the caller.
The retry is really just that, retry and if it fails just fail (like it could fail the first time, under normal conditions, as well).
Repeating two simple lines of code (not even business logic) isn't really a problem.
|
|
|
|
|
If that was the problem the author of that code tried to 'fix', (s)he should've added a comment to indicate that.
|
|
|
|
|
Even though I consider comments to be one of the evils of programming I agree with you on this one
|
|
|
|
|
If your comments do not fill at least one third of your code, copy & paste until it does!
|
|
|
|
|
We actually had such a rule.
Our automated build system would keep giving us errors "At least 25% of a file must be comments." 
After some insistence from my part they disabled that rule
|
|
|
|
|
Being a rather elderly gentleman, I am very religious in my documentation. I know I will be maintaining my own code and will not remember why I did something. Most of my documentation is the "why" I did something or "how" it works, but occasionally I justify to myself why a particular construct or pathway was chosen. My code is self-documenting as far as it can be, but comments still give me quicker access to the areas that need modified/added. In addition, since the compiler doesn't care about whitespace, I use it systematically to separate blocks of code or related groups of commands from the rest.
Now when it comes to resources, I will use whatever the language supplies with the only limitations being running efficiently and being easy to read. I am as likely to use a generic list as I am a hash table depending on what is required.
|
|
|
|
|
Congratulations on successfully disabling the rule!
|
|
|
|
|
I don't like the way it is phrased.
If you phrase it: "At least 25% of the lines should be explained by a comment", then I agree. Leaving more than 75% as "self explanatory" is very costly, five years later.
I am very fond of end-of-line comments; they can be made short, to the point, and at the right place. If you need something between the software architecture documentation (I often describe "software architecture" as "the structures that will remain the same if you reimplement the system in a different programming language"), a comment block may apply to, say, an entire function, or at least the core part of it.
From the moment you compile a source file for the first time and three weeks thereafter, any code is "self explanatory". After two years, not even the code written by yourself qualifies. A classic: Geek & Poke[^]
|
|
|
|
|
Depends, most of the code is just properties, setting, getting, some database queries, standard stuff.
I always get a little sad when I see comments like:
someVar = someVal;
foreach (Product p in products)
customer.Save();
product.Save(); Unfortunately, I've only seen comments like that.
And because of these kind of comments I came to detest them.
You may think I'm overreacting, but those are actual real-life comments I see almost daily.
I have 7 years of experience and I have yet to find a single comment that is actually helpful.
I rarely comment my code, maybe once or twice when there were some weird side-effects (which is just bad code).
I'm at the point that I prefer my code uncommented (especially when it's bad code, people who write bad code also write bad comments).
Yeah, comments can't be done right.
|
|
|
|
|
Have you been reviewing your own code years later?
At the beginning I was like you, but then I started having to upgrade my own code... I ended writing comments where needed
note: I say where needed, not overall. But... if not sure, the default is... comment, better one too much than one too few.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
