O tratamento de exceções é uma preocupação transversal?


13

Não vejo muita diferença entre as preocupações de manipulação e log de exceções, pois ambas são preocupações transversais. O que você acha? Não deveria ser tratado separadamente por si só, em vez de intercalado com a lógica central que um método está implementando?

EDIT : O que estou tentando dizer é que, na minha opinião, a implementação de um método deve conter apenas a lógica para o caminho bem-sucedido da execução, e as exceções devem ser tratadas em outro lugar. Não se trata de exceções marcadas / desmarcadas.

Por exemplo, um idioma pode manipular exceções de uma maneira totalmente verificada usando construções como esta:

class FileReader {

  public String readFile(String path) {
    // implement the reading logic, avoid exception handling
  }

}

handler FileReader {

   handle String readFile(String path) {
      when (IOException joe) {
        // somehow access the FileInputStram and close it
      }
   }

}

Na linguagem conceitual acima, o programa não será compilado na ausência de FileReader manipulador , porque o readFile da FileReader classe não está lançando a exceção. Portanto, declarando o FileReader manipulador , o compilador pode garantir que ele está sendo manipulado e o programa compila.

Dessa forma, temos o melhor dos problemas de exceção verificados e não verificados: robustez e legibilidade.

Respostas:


14

Em alguns casos sim

Nos casos em que você tem uma exceção que deseja registrar (o que eu suponho ser quase sempre), sim, a exceção está ligada a uma preocupação transversal.

Na maior parte do tempo, não

No entanto, tome a instância de um SocketListener, se um socketlistener lança uma exceção devido à outra extremidade que interrompe a conexão, esse comportamento deve ser antecipado e, portanto, o aplicativo deve agir de acordo com as circunstâncias que causaram a exceção. Isso não é algo que um Aspect genérico deva lidar e, portanto, não deve ser uma preocupação transversal.

Identificando uma preocupação transversal

Se você estiver duplicando o mesmo código repetidamente, ele precisará ser abstraído. Se a abstração se promover a várias camadas, pode ser uma preocupação transversal. Só então deve ser considerado.


4

O registro é opcional. Manipular exceções não é.

O registro é bastante genérico e, embora origine de lógica específica, ele alimenta um consumidor genérico. As exceções são sempre específicas da lógica e algum código conhecedor dessa lógica precisa lidar com a bagunça que ela fez.

Pelo menos no meu uso limitado dos dois, isso significa que os dois objetivos são melhor tratados de maneiras diferentes e não sob o mesmo design.


1

Eu vejo o tratamento de exceções como uma preocupação transversal para certos tipos de exceções. Há exceções locais que apenas o código de chamada imediata pode manipular corretamente. Um exemplo pode ser uma exceção do banco de dados ao tentar executar uma consulta. Mas também há exceções que podem e devem ser tratadas de maneira mais global. Um exemplo pode ser uma exceção relacionada à falta de credenciais de segurança (force o usuário a efetuar login novamente). Ou, no mínimo, você precisa de um manipulador global, caso ocorra uma exceção no código mais específico, para explicar ao usuário o que ele deve fazer para reiniciar ou enviar um log para a TI ou algo assim. Para esses tipos de exceções tratadas globalmente, é uma preocupação transversal.


0

Eu acho que isso está relacionado à questão das abstrações com vazamentos.

Muitas exceções devem ser capturadas e reapresentadas à medida que se propagam pelas camadas da abstração. O relançamento deve lançar a exceção em uma nova forma, apropriada para a abstração que está realizando o relançamento, para que faça sentido como parte da interface. Em outras palavras, as exceções de níveis mais baixos de abstração devem ser traduzidas para a forma de abstração atual, para que os níveis mais altos de abstração não precisem saber sobre os níveis mais baixos, mesmo puramente para o tratamento de exceções.

No entanto, o "princípio das abstrações com vazamentos" é um problema. Algumas exceções não podem ser traduzidas para um formulário que faça sentido na próxima camada de abstração.

Uma exceção relacionada ao sistema de arquivos em rede é um exemplo simples. Uma falha de rede não pode ser expressa em termos que façam sentido para uma abstração de "arquivo" ou, se houver, essa abstração realmente não abstraiu completamente todos os detalhes relacionados à implementação do tratamento de arquivos.

Portanto, uma falha na rede vazaria da abstração da rede subjacente e, portanto, deve ser uma preocupação transversal no restante do código.

Isso não é exclusivo de exceções, no entanto. Todos esses códigos de erro de valor retornado para APIs de arquivos que não estão realmente relacionados à abstração do arquivo, mas detalham o disco rígido ou a rede ou quaisquer falhas são a mesma coisa em uma forma diferente, implicando que falhas no disco rígido e falhas na rede etc, são preocupações transversais, independentemente de como essas falhas são relatadas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.