Is a 'recoverable error' interface more efficient than handling recovery in multiple 'catch' blocks?

问题

So, this is a re-ask of another question that was closed for being opinion based. So I'm re-asking my question in a more factual manner.

So, as the title says, I'm unsure if I should try to implement recoverable error classes or just stick with trying to recover in a catch block.

Some psuedo-code to demonstrate:

// more or less what I have now
postToServer(data) {
    try {
        socket.write(data)
    }
    //Interrupted being a custom exception
    catch(Interrupted ex) {
        //happened twice is a common static method on all custom exceptions that returns a boolean indicating if the last thrown error is the same as this one
        if(Interrupted.happenedTwice(ex)) throw ex;
        else postToServer(data);
    } 
    //another custom exception indicating that the network is unreachable
    catch(NetworkDrop ex) {
        if(!NetworkDrop.happenedTwice(ex) && !reconnectToServer()) throw ex;
        else postToServer(data);
    }
}
//What I would like to implement
interface Recoverable {
    public void recover(Runnable) throws Exception;
}
class NetworkDrop extends Exception implements Recoverable {
    ...
    public void recover(Runnable resume) {
        if(!NetworkDrop.happenedTwice(this) && reconnectToServer()) resume.run();
        else throw this;
    } 
}
class Interrupted extends Exception implements Recoverable {
    ...
    public void recover(Runnable resume) {
        if(!Interrupted.happenedTwice(this)) resume.run();
        else throw this;
    }     
}
postToServer(data) throws Exception {
    try {
        socket.write(data)
    }
    catch(Recoverable ex) {
        ex.recover(() -> postToServer(data));
    }
}

As the example, I'd like to have all the recovery code in the exception (reduces duplicate code, as now say 5 different methods can just call recover instead of running the same recovery code). This would allow me to catch exceptions that can be recovered, but still throw unrecoverable ones, or throw if recovery can't be done.

I see an issue with this though:

How would I recover inside a method that is expected to return data, when the intermediate Runnable called from recovery doesn't return data? Say hypothetically I'm reading from the server instead of writing, and get a recoverable exception (such as NetworkDrop) and successfully recover. Since execution is resumed through the Runnable on the recover method, and Runnable doesn't return anything, so how would the function that called the read get the data out of the Runnable?

So, would this system be more efficient that multiple catch's? Or is the readability and simplicity I get from only catching recoverable exceptions a double edged sword?

And if the tradeoff favors Recoverable classes, how would I address the issue of getting a return value from a recovered exception?

来源：https://stackoverflow.com/questions/65013014/is-a-recoverable-error-interface-more-efficient-than-handling-recovery-in-mult

标签

java

exception