通过

C#: Linked by the great Raymond Chen

  • 项目

So I won an Oscar too :) and was honored with a link from Raymond Chen. Sometime back I posted on including try/catch/retry block in C# and he is recommending not using such automatic retrying. However, I do not agree with the flat recommendation and I think this varies based on the scenario.

This is what I replied to his post....

I agree that just retrying does not work in all situation. In  https://blogs.msdn.com/abhinaba/archive/2005/10/01/476026.aspx
the example I used does not arbitrarily  retry the operation 3 times. It uses an Exception class which explicitly uses a public member to signal whether the operation is retryable.

In all situations asking the user for retrying does not work. Lets take the example of one of the source code repository converters we are working on. This takes a VSS repository and migrates all data in it to Team Foundation Server repository. This includes thousands of files and hundreds of versions of each of them amounting to 10s of GB of data and takes a day to migrate. In this super-high stress situation VSS server sometimes acts-up and either times-out or throws an error. So what do we do, expect the user to sit around for the whole day and see each failure and prompt him Retry (Y/N)? or fail the migration that was going on for the last 8 hours?

My point is in some situations like an interactive program (UI client) prompting the user for retry is the correct thing to do. In long running un-attended batch conversion job where we know for sure that transient failures occur and get resolved on retrying, using retry is the right approach.

Comments

  • Anonymous
    November 07, 2005
    I'm jealous!!
  • Anonymous
    November 07, 2005
    The correct thing to do is not prompt to see if the user wants to retry the operation, but to retry the operation with UI that allows them to cancel.

    The dial-up networking works like this when dialing, I believe. It says what the error was ("Busy", "No carrier") how many retries it has left and how many seconds until the next retry. If you're there you can cancel it at any time, but if you're not then it will eventually make the connection or fail with no user intervention.
  • Anonymous
    November 08, 2005
    I think I agree with both of you... In general, you should probably think hard before doing any sort of "automatic retries" but at the same time, you don't need to discount them completely.

    I guess Raymond's coming from a shell perspective which is very user-centric (like explorer or outlook or something), whereas you're coming from more of a server perspective where there is no user to necessarily decide whether to retry an operation or not (or at least, in the example you gave, the user isn't going to be around the whole time).

    Personally, I think the best compromise is to fail-fast by default, and only if you find a problem and decide later that retrying might fix it do you actually do it.