Thoughts On Handling Exceptions in This App
-
I'm working on a WPF app that connects to SharePoint. From time to time, upon connecting, I get a 'Server not availale' exception. Sometimes I get the error while downloading data. It's intermittent and I can't seem to reproduce it. I restart the app and it works fine. I could just catch it and retry, but I'd like to get your thoughts on the best way to deal with this.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
-
I'm working on a WPF app that connects to SharePoint. From time to time, upon connecting, I get a 'Server not availale' exception. Sometimes I get the error while downloading data. It's intermittent and I can't seem to reproduce it. I restart the app and it works fine. I could just catch it and retry, but I'd like to get your thoughts on the best way to deal with this.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
If you're downloading "a lot of data" (or processing), you take "check points" so you don't have to "restart the app" from the beginning. This assumes the app (or "query") can restart / continue from a check point / sync point.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I'm working on a WPF app that connects to SharePoint. From time to time, upon connecting, I get a 'Server not availale' exception. Sometimes I get the error while downloading data. It's intermittent and I can't seem to reproduce it. I restart the app and it works fine. I could just catch it and retry, but I'd like to get your thoughts on the best way to deal with this.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
GitHub - App-vNext/Polly[^] is "a .NET resilience and transient-fault-handling library that allows developers to express policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback in a fluent and thread-safe manner." As recommended by Microsoft[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I'm working on a WPF app that connects to SharePoint. From time to time, upon connecting, I get a 'Server not availale' exception. Sometimes I get the error while downloading data. It's intermittent and I can't seem to reproduce it. I restart the app and it works fine. I could just catch it and retry, but I'd like to get your thoughts on the best way to deal with this.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
It is an external server. One should always design and code with the expectation that external calls will fail. They can fail for the following known intermittent reasons. 1. The server is down 2. The network is having issues. They can fail repeatedly for following reasons. 1. Something is incorrectly configured. 2. Your code is not correctly setting up the call. (Credentials, wrong message, invalid message, etc.) There can be processing issues 1. The server never responds 2. The server takes too long (a timeout is exceeded.) 3. The server has an internal error and returns an error code. 4. The server returns an error code that suggests a retry is possible. 5. The server returns an error code that suggests a retry is not possible. There can be other known/unknown reasons not in the lists above. You can choose to implement a retry strategy but that can only work for some of the cases above. The problem with retry strategies is the following 1. Are there situations where it must not be retried? For example if you just attempted to update the inventory by removing (data) 10 items do you want to keep retrying that again and again for every possible error? That could be a problem if the server is in fact succeeding (the 10 were removed) but then fails when attempting to format a correct response back to you. 2. Are there situations where it will never work so retries are pointless? One must also evaluate what retry strategies can do to the entire enterprise. For example if simple retries are in place and there is a chain of 5 services that keep retrying (service A retries B which retries C etc) what happens to the original caller while they wait? Even more complicated what happens with timeouts? If service B has three retries at 90 seconds each and service A also looks for timeouts then a single call to B would require a minimum timeout of 270 seconds in A. And B would need 3 of those. Presuming of course that A even knows that B is using a timeout like that.
-
I'm working on a WPF app that connects to SharePoint. From time to time, upon connecting, I get a 'Server not availale' exception. Sometimes I get the error while downloading data. It's intermittent and I can't seem to reproduce it. I restart the app and it works fine. I could just catch it and retry, but I'd like to get your thoughts on the best way to deal with this.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
You can find a solution in recommendations X.215/X.225 ... :-) We did have a standardized solution to this 40 years ago, in 1984. But it was too ambitious - you couldn't give IT students a homework assignment of implementing the OSI Session Layer. You could have them making a primitive implementation of, say, (too) Simple Mail Transfer Protocol, (too) Simple Network Management Protocol or (too) Simple File Transfer Protocol. Besides, the Internet standards were freely available, while OSI specs were copyrighted and expensive. So the Internet Protocol Suite won the war against OSI. In 1984, you may say that OSI Session was overkill (considering resources available at the time). If it had been generally available for 40 years, we certainly wouldn't have considered it overkill today. There might be running implementations out there, even today, but I don't know of any.
