Como você decide entre uma exceção checked e uma unchecked, e como você trata exceções em um serviço?

Use uma exceção checked só quando quem chama pode realisticamente se recuperar e você quer que o compilador force uma decisão; use unchecked para erros de programação e para falhas que ninguém acima na pilha consegue resolver. Na prática, a maior parte do Java moderno pende para unchecked, embrulhando falhas de baixo nível numa exceção de domínio que carrega contexto, tratada uma vez em uma fronteira, como um exception handler que a mapeia para uma resposta.

Meu teste é se quem chama pode fazer algo útil com aquilo. Um pagamento recusado pelo provedor é um desfecho de negócio legítimo, então isso é ou uma exceção checked ou, mais comumente, um tipo de resultado. Um argumento nulo ou uma conexão de banco que falhou não é algo que o código chamador consegue consertar, então é unchecked. Em serviços eu uso principalmente exceções de domínio unchecked, embrulhando a causa original para que o stack trace sobreviva e adicionando os identificadores que eu vou querer no log, como o id do pedido, já que uma SQL exception pelada três camadas abaixo não me diz nada. O tratamento acontece uma vez, numa fronteira: no Spring isso é um exception handler que mapeia cada exceção de domínio para um status code e um corpo de resposta, então os controllers ficam limpos. O que eu contesto em review é capturar Exception de forma ampla, capturar e logar e seguir como se nada tivesse acontecido, e blocos catch vazios. Eu também uso try with resources em todo lugar em vez de blocos finally, porque exceções suprimidas e falhas no close são tratadas corretamente de graça.