1

I have a process that can get stuck in an infinite loop and I want to add a 5 second timeout so it doesn't hang forever. 

bool FlagSuccess = false;
while (FlagSuccess == false)
{
    try
    {
    //Blah blah blah
    FlagSuccess=true;
    }
    catch
    {
    }
}
sooprise
  • 22,657
  • 67
  • 188
  • 276

1 Answers1

2

This is construct I try to avoid. But if you must:

bool FlagSuccess = false;
DateTime timeout = DateTime.UtcNow.AddSeconds(5);
while (FlagSuccess == false && DateTime.UtcNow < timeout)
{
    try
    {
    //Blah blah blah
    FlagSuccess=true;
    }
    catch
    {
    }
}
Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
  • You need to change it to add 5 Seconds, not 5 minutes – Iain Ward Jul 08 '10 at 15:29
  • I'm open to trying different things. What type of construct would you recommend I use? I'm very new to C#, and a lot of my code is just me fumbling in the dark. I'm happy to learn more "standards friendly" code practices while I'm still green. – sooprise Jul 08 '10 at 15:32
  • I'd change that to `DateTime.UtcNow` otherwise you run the risk of either not spinning through the loop at all (really bad) or spinning through for more than an hour (slightly bad). – Brian Gideon Jul 08 '10 at 15:44
  • @Brian, can you explain to me how this loop running error could occur? If you're using DateTime.Now, I can only imagine it running into the error you describe if the timezone was changed while it was running... – sooprise Jul 08 '10 at 15:54
  • @Soo: If you are in a region that observes daylight saving time then the spring transition jumps the time forward one hour and the fall transition jumps back one hour. I think you can visualize what happens from there. This is one among many reasons why it is always best to do **all** date/time processing in UTC. I have to deal with issues like these on daily basis that is why I am so padantic about it :) And yes, changing the timezone would also do it, but coding against that is on the verge of paranoia. – Brian Gideon Jul 08 '10 at 16:08
  • @Brian, Sorry if I'm being a jackass, I just want some clarification on the Now vs UTCNow issue. In the code example above (the one with the timeout), would a daylight savings time change only cause an hour/noLoop error if it occurred during those 5 seconds? – sooprise Jul 08 '10 at 17:15
  • 1
    @Soo: Yes, that is correct. So if we have a 5s problem window that occurs twice in a year and if you assume that the code is started say every minute then you would have a 1 - (1 - 5/60)^2 = 0.16 = 16% probability of encountering the problem in a year. The odds drop significantly to only 0.3% if the code only runs every hour. Normally I would say weigh the risk versus the difficulty of the solution except in this case fixing the problem is so incredibly easy that you might as well use `UtcNow` and call it day. – Brian Gideon Jul 08 '10 at 17:35
  • @Brian, ok very good, thanks for that explanation. Knowing that there is a 16% chance per year of this error happening is enough for me to use UTCNow for this situation (and now I understand UTCNow well enough to use it in the future when warranted)

    Thanks much! :D     – sooprise Jul 08 '10 at 18:17