| > If you want to retry a particular failing operation, you write try/catch around IT, not several levels up the stack. Generally speaking when I retry and operation it's pretty far up the stack that I restart it. I'm not retrying sending a single byte, I'm retrying the entire file transfer operation (as an example). If it's batch job processing data in a loop, then the processing of each item is typically where I would catch and retry or ignore. If the exception actually said "I think you should retry" then it could retry otherwise it would abort. > To convey meaningful semantic information about the (business) operation that failed. Wrapped exceptions tend to provide less information than the root exception. I agree that library authors aren't as careful as they could be about exceptions and you might need to wrap an exception just to make it sane. Generally most libraries throw LibraryException and the real exception, with meaningful information you can action, is in the inner exception. I blame Java's checked exceptions for making that a thing. > But the exception type does not have that flag. Right. That's why I proposed it. "If base exception type had a single property... something like "CanRetry"... all exception handling would be simple." > To the program it looks the same as ordinary timeout error. How temporary is it? Never forget to put a limit of retries. You could get really clever and put an exponential delay on it. |