Updated Lazy<T> paragraph to be more general

Author: asasine

articles/azure-cache-for-redis/cache-failover.md

@@ -62,7 +62,7 @@ Whenever a failover occurs, the Standard and Premium caches need to replicate da
 
 The number of errors seen by the client application will depend on how many operations were pending on that connection at the time of the failover. Any connection that is routed through the node that closed connections will see errors. Many client libraries can throw different types of errors including timeout exceptions, connection exceptions, or socket exceptions when connections break. The number and type of exceptions depends on where in the code path the request is when the cache closes its connections. For instance, an operation that sends a request but hasn't received a response when the failover occurs may get a timeout exception. New requests on the closed connection object will receive connection exceptions until the reconnection happens successfully.
 
-Most client libraries will attempt to reconnect to the cache if configured to do so but they can occasionally get into a bad state and require the entire connection object to be recreated. For recreating the connection without restarting the application, see [this sample code of a Lazy\<T\> pattern](https://gist.github.com/JonCole/925630df72be1351b21440625ff2671f#reconnecting-with-lazyt-pattern).
+Most client libraries will attempt to reconnect to the cache if configured to do so but unforseen bugs can occasionally place the library objects into an unrecoverable state. If errors persist for longer than a pre-configured amount of time, the connection object should be recreated. In .NET and other object oriented languages, recreating the connection without restarting the application can be accomplished using [a Lazy\<T\> pattern](https://gist.github.com/JonCole/925630df72be1351b21440625ff2671f#reconnecting-with-lazyt-pattern).
 
 ### What should I do in my application?