> Retrying is relevant for a specific small segment of callsites dealing with unreliable network or hardware interactions. This fact and knowledge of it should

> Retrying is relevant for a specific small segment of callsites dealing with unreliable network or hardware interactions. This fact and knowledge of it should inherently be obvious at the callsite. Yes. However, libraries, at least in .NET world, are notoriously bad at documenting what exceptions are thrown in what circumstances. Example: trying to execute an SQL statement against a server and the network connection drops. Do I get SqlException, SocketException, or SqlException containing an inner exception that is (hopefully) SocketException or TimeoutException. Link to docs: https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlcommand.executereader?view=dotnet-plat-ext-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlc... It mentions network outage, but specifically only for streaming operations, while most queries are decisively not in that category. So what exception should the program catch to handle the case of network outage so that it can sleep and retry? It's also extremely difficult to test an outage of an intermediate router/switch because unplugging the network cable tells the OS that the media is gone, which immediately signals an error to programs depending on that interface. (Though possible to mock with FW rules...)