Clutter de exceção, quão necessário é? [duplicado]

5

Digamos que eu tenha alguns métodos que acessam o sistema de arquivos, e eu quero que eles sejam um pouco robustos, eu quero lançar erros para que o usuário possa reagir:

  • Se o arquivo não tiver direitos de leitura / gravação, quero informá-lo.
  • Se o arquivo não existir, desejo que ele escolha outro.

E assim por diante.

A coisa é, as exceções estão bagunçando o código um pouco:

  • FileNotFoundException : bastante necessário, o arquivo não foi encontrado, tente novamente ou desista.

  • IOException : geralmente é quando o arquivo não pode ser lido por qualquer motivo.
    Estava lá, mas agora não, você não tem mais direitos de acesso, algo deu terrivelmente errado. Geralmente este é um ponto de parada, mas ainda assim o usuário poderia escolher outro arquivo ou algo assim, eu preferiria não trave o aplicativo.

  • InvalidPathException : o desenvolvedor ou o usuário tentou dar um erro caminho (como incluir um caractere ilegal no nome do arquivo, novamente, o aplicativo não deve travar por causa disso.

No meu caso, eu diria que todas essas exceções são importantes porque o IOE captura o FNFE, mas elas são resolvidas diferentemente, e embora o FNFE e o Invalid Path sejam semelhantes, ainda tenho que jogá-los separadamente, mas pelo menos localizá-los juntos.

Minha pergunta é

Quando as exceções começam a se acumular, o código começa a ficar feio, suponho que não há trabalho para isso?

    
por Kalec 28.09.2015 / 13:00
fonte

2 respostas

5

Como o fluxo deve ser o mesmo com os três tipos de exceções:

  • O usuário escolhe um arquivo
  • Se o arquivo não puder ser aberto (seja porque o arquivo não existe, está bloqueado, caminho inválido, ...), peça a ele uma mensagem personalizada
  • Permitir que o usuário tente novamente a operação

Sugiro criar uma classe personalizada herdada de Exception . Nesta exceção você deve quebrar:

  • a exceção original (IOE, FNFE, IPE) para preservar o stacktrace
  • uma mensagem personalizada que pode ser exibida para o usuário (ou uma chave para uma string i18n se você precisar)

Exemplo:

public final class FileException extends Exception {
    public FileException(String message, Throwable cause) {
        super(message, cause);
    }
}

O passo mais importante no seu código é lançar um FE assim:

try {
    //some operation that can throw an FNFE
}
catch(FileNotFoundException e) {
    throw new FileException("The file doesn't exist !", e);
}
    
por 28.09.2015 / 13:31
fonte
3

Confine a desvantagem necessária por várias exceções ao menor escopo possível e, em seguida, envolva-a em seu próprio tipo de exceção que preserve todas as informações originais.

Para elaborar: digamos que você tenha que lidar com FileNotFoundException , PermissionsException , ReadOnlyFileSystemException e invalidpathException , e todos eles não têm um super tipo comum (ou você não quer diluir informação que muito por captura simples IOException ). O que você deve fazer é escrever um método que capture todas essas exceções diferentes e repita um PreferencesException auto-escrito em todos os casos, apenas anotado com as informações de erro orignal, se necessário. Dessa forma, todos os outros métodos em sua base de código só precisam lidar com esse tipo de exceção (ou possivelmente sem nenhum tipo se o novo tipo de exceção não for uma exceção verificada).

    
por 28.09.2015 / 13:31
fonte