If it fails, try again
-
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();
}:laugh: :thumbsup: Really should be in a loop 42 times! 42 times always work out nicely! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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();
}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).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
:laugh: :thumbsup: Really should be in a loop 42 times! 42 times always work out nicely! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
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 :laugh:
-
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 :laugh:
This calls for a do-while! xD
bool failure = true;
do
{
try
{
//connect to dbfailure = false; } catch(Exception e) { failure = true; }} while (failure);
-
This calls for a do-while! xD
bool failure = true;
do
{
try
{
//connect to dbfailure = false; } catch(Exception e) { failure = true; }} while (failure);
See [Einstein's definition of insanity](https://www.brainyquote.com/quotes/quotes/a/alberteins133991.html).
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'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).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
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 :D
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
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 :laugh:
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.
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
Even though I consider comments to be one of the evils of programming I agree with you on this one :D
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
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).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
Once had an issue with a rather unstable connection that often made it fail the first time.
This reminds me of a funny story where a customer kept having intermittent issues with our software...database connections kept timing out. :confused: Every time the guy would call having problems, I would remote in, and the problem wouldn't happen. Luckily, they were within driving distance, so I went onsite to try and sort it out. The end user's office was across the driveway to a shipping dock and warehouse. The database server was located in the warehouse office, and the network connection between the two offices was a p2p (line of sight) wireless setup. (apparently a short term solution while they were constructing new offices) When I arrived, there wasn't a lot going on...the software worked without fail. After a while, a truck arrived and began backing into the dock...and suddenly, the database connection was gone! :omg: For weeks, the customer never made the 'connection'! Luckily, the fix was simply raising the p2p units by a few more feet.
"Go forth into the source" - Neal Morse
-
See [Einstein's definition of insanity](https://www.brainyquote.com/quotes/quotes/a/alberteins133991.html).
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...
-
Sander Rossel wrote:
Once had an issue with a rather unstable connection that often made it fail the first time.
This reminds me of a funny story where a customer kept having intermittent issues with our software...database connections kept timing out. :confused: Every time the guy would call having problems, I would remote in, and the problem wouldn't happen. Luckily, they were within driving distance, so I went onsite to try and sort it out. The end user's office was across the driveway to a shipping dock and warehouse. The database server was located in the warehouse office, and the network connection between the two offices was a p2p (line of sight) wireless setup. (apparently a short term solution while they were constructing new offices) When I arrived, there wasn't a lot going on...the software worked without fail. After a while, a truck arrived and began backing into the dock...and suddenly, the database connection was gone! :omg: For weeks, the customer never made the 'connection'! Luckily, the fix was simply raising the p2p units by a few more feet.
"Go forth into the source" - Neal Morse
Customers do that :laugh: I have a similar story with a printer. The user pressed the print button to print somewhere around 100 to 150 invoices. It often happened that the printing stopped after 50 or so invoices. And always at the end of the day (because that's when they printed invoices). So I was testing my software, looking for bugs, writing "fixes" for "what could be it", added additional logging, everything, but I was never able to find the problem. And when I visited it didn't happen, of course. This went on for weeks. Then my manager visited them, for completely unrelated business, and called me "Is that print problem fixed already? I'm about to leave, but they're going to print invoices so I can check on them now." He checked and you'll never believe what their issue was. They clicked the print button and SHUT DOWN THEIR COMPUTER TO GO HOME!!! :wtf: :omg: :~ X| Never did it occur to them that shutting down the computer would stop it from printing. I can tell you I felt like driving a truck over their computers! :laugh:
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
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." X| After some insistence from my part they disabled that rule :D
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
We actually had such a rule. Our automated build system would keep giving us errors "At least 25% of a file must be comments." X| After some insistence from my part they disabled that rule :D
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
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.
-
We actually had such a rule. Our automated build system would keep giving us errors "At least 25% of a file must be comments." X| After some insistence from my part they disabled that rule :D
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
Congratulations on successfully disabling the rule!
-
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();
}Probably not much help when a parachute does that.
Arguing with a woman is like reading the Software License Agreement. In the end, you ignore everything and click "I agree". Anonymous
-
Customers do that :laugh: I have a similar story with a printer. The user pressed the print button to print somewhere around 100 to 150 invoices. It often happened that the printing stopped after 50 or so invoices. And always at the end of the day (because that's when they printed invoices). So I was testing my software, looking for bugs, writing "fixes" for "what could be it", added additional logging, everything, but I was never able to find the problem. And when I visited it didn't happen, of course. This went on for weeks. Then my manager visited them, for completely unrelated business, and called me "Is that print problem fixed already? I'm about to leave, but they're going to print invoices so I can check on them now." He checked and you'll never believe what their issue was. They clicked the print button and SHUT DOWN THEIR COMPUTER TO GO HOME!!! :wtf: :omg: :~ X| Never did it occur to them that shutting down the computer would stop it from printing. I can tell you I felt like driving a truck over their computers! :laugh:
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
True story. Some users seems to assume that printers have internal memory which would keep our queued documents. This assumption comes from a fact that printer keeps printing even when they closed our software. They don't know that these queued documents are stored on operating system's printer spooler service. Some colleagues once asked me, why did her printer stop printing? I who was in the middle of serious work mode, glanced over at her desk and yelled, you turned off your computer, that's why!
-
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();
}If "try again!" always was silly coding practice, the the concept of "busy waiting" would not be known. Busy waiting does have its place, especially in embedded systems where the processor has nothing else to do. Another situation is where several activities are competing for the same resource, but they hold the resource comparatively briefly. As long as you can modify all the competitors, you could program the queueing mechanism, where a process trying to access a busy resource is sent to sleep in a queue and woken up when it gets its turn. Often you can only modify some of the competitors. The effort of implementing a queue mechanism may be high. If the risk of collision is small, it simply doesn't pay. I have fairly recently programmed a couple "try again" cases: On a quite heavily loaded file system, the number of exceptions due to confliciting accesses was higher than desired. So, when making modifications to a set of files, I make one try for each. Those failing are put into a list for retrying, and a second attempt is made once the first round was completed. Only after a second try, the user is notified. We went from too many access collisions to almost none. Sometimes, the second try came too fast, and the file was still busy. So I added a 5 ms sleep before starting a second round, and after that I haven't seen a single collision. This "try again" code is next to trivial, and it does solve a real problem. So I cannot agree that the strategy is silly in every case. Sometimes it makes perfect sense.
-
We actually had such a rule. Our automated build system would keep giving us errors "At least 25% of a file must be comments." X| After some insistence from my part they disabled that rule :D
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
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[^]
