Imagine a seguinte situação:
Você tem a assinatura de um método em uma interface de terceiros onde você o implementa em uma classe sua. Na implementação, você precisa de um try{…}cath{…}, daí você percebe que a responsabilidade de tratar esta exceção não é desta classe e sim de que faz uso dela, porém como na assinatura da interface não está descrito que ela lance esta exceção, como poderia resolver este problema?
Coloca try-catch e da um throw numa RuntimeException. Nao esquece de colocar no javadoc que vc vai fazer isso.
Rafael
Quebra de contrato detected.
Uma runtime exception nesse caso só vai mascarar a exceção, o que não é legal proque a cliente da interface está esperando que você siga o contrato estipulado.
A melhor maneira é você encapsular a exceção dentro de uma das publicadas pela interface, desde que seja coerente, mas se a exceção é tão alienígena assim, a primeira coisa que penso é que a classe implementadora pode não estar coesa, pdoe estar fazendo coisas que não são da conta dela. Um rafactoring pode cair bem.
Na piro das hipóteses (código fechado e prazo apertado), a gambiarra sugerida pelo rafael pdoe funcionar, mas seu uso deve ser feito com um cuidado extremo, isso pdoe quebrar um sistema em produção fácil fácil.
Mesmo que delegue para outra classe fazer o trabalho que lanca a exception, ele vai ter que tratar caso seja uma checked. Alguem vai ter que tratar. Um refactoring nesse caso me parece que somente iria jogar o problema para outro lugar.
Rafael
A questão não é ter que tratar, a questão é o que tratar.
Você fechou um contrato onde diz quais exceções serão lançadas, e você está quebrando este contato, não está garantindo sua pós-condição.
Ok, a teoria eh linda, concordo. Mas e a aplicacao real? E se o tal contrato tiver sido mal planejado? (ou se nem consideram os usos reais). Com contrato ou sem contrato, ha uma checked exception a ser tratada, em algum ponto.
Como vc faria? pq eu grotescamente apelaria para a runtime.
Malditas checked exceptions que soh servem para complicar o dia-a-dia.
Rafael
A nao ser que o refactoring inclua modificar a interface que originou a dor de cabeca toda 
Eu mencionei acima:
Opções
1 - Refactoring
2 - Gambiarra de Runtime
Na ordem. Eu concordo que muita coisa teórica é complicado de ser implementado, mas eu acredito que mutias vezes um sentimento de “na prática nunca é assim” atrapalha :(.
Opa, eu nao queria dizer que “na pratica NUNCA eh assim” :). Estava mais me referindo a esse caso em especifico.
Considerando que um refactoring na interface nao eh uma opcao, e deixando de lado a “gambiarra”, o que vc sugere / como faria? (serio, eu nao tenho mtas ideias 
)
Rafael
Acho que enste caso mesmo se as exceções lançadas pelo método forem realmente muito diferentes da que o processamento obteve (mesmo se não for tão diferente assim já pede um refactoring, mas nesse caso… ), acho que eu empacotaria a exceção obtida numa delas e faria um log imenso.
Também não consigo pensar em nada muito bonito nesse caso
=/