3 ms·
> you should not be defensively programming against all those possibilities This is where libraries and frameworks come into play - they defensively program ag
by bluepizza 3y ago
> 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 3y agoIf 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 3y agoError 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 3y agoError 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.