[bluepizza]

> you should not be defensively programming against all those possibilities

This is where libraries and frameworks come into play - they defensively program against that for you. And wrap it all up in a simple interface with, well, checked exceptions.

[jdm2212]

If I need to write some bytes to an S3 bucket but the network is hosed, there's literally nothing useful I or any library can do until the network is back up.

RPC calls will fail, error logs should get written, and a monitor should get triggered, and someone should get paged so they can wake up and figure out why the network is hosed.

Nowhere in there is it useful for me to wrap all my S3 writes in try/catch blocks.

[zaphirplane]

Error logs and monitor needs to known the operation failed somehow, try/catch or return value.

> literally nothing useful I can do

For some services, for others queuing the operation for retry is a thing.

[jdm2212]

Error logs and monitors find out because the RPC fails, which causes an error to be logged and a failed request metric to be incremented. (The UncaughtExceptionHandler will do the same for stuff failing in background threads.)

If eventual consistency is important, enqueuing for retry has to be done BEFORE you try to write, not on write failure. If/when the write succeeds, you remove the item from the retry queue.