Você tem alguma orientação da equipe sobre exceções? [fechadas]


8

Minha equipe herdou recentemente um projeto de uma equipe em que a quantidade de desenvolvedores caiu tão baixo que eles tiveram que descarregar algum trabalho. Um dos projetos que herdamos foi um projeto repleto de códigos aninhados e um tratamento terrível de exceções (as exceções foram tratadas como instruções goto e, portanto, usadas como parte do fluxo normal do programa).

No fim das contas, era uma bola de código cabeluda que alguém vinha tossindo há alguns anos.

Agora, temos algumas diretrizes de equipe em vigor há algum tempo, mas todos os aspectos relativos às estruturas dos objetos, estilos de codificação e outros. Mas não cobrimos o tratamento de exceções.

Então, eu estou pensando se você tem alguma orientação em suas equipes em relação ao tratamento de exceções e, em caso afirmativo, como você as aplica?


Você quer dizer aplicação social ou aplicação tecnológica? Existem muitas ferramentas de análise de código estático para detectar padrões de exceção abusados.
MatthewMartin

Bem, ambos realmente.
Morten

Pode ser mais simples refatorar o código para verificar as pré-condições primeiro e retornar da função mais cedo se alguma pré-condição não for atendida. Além disso, vários gurus importantes consideram finally(lógica de reversão) a parte mais valiosa de um sistema de tratamento de exceções.
Rwong 14/05

Respostas:


4

Embora não sejam diretrizes oficiais para qualquer equipe em que já participei, considero que as exceções devem ser usadas apenas para condições realmente excepcionais ou quando você absolutamente (por algum motivo) precisa levantar as mãos e deixar o interlocutor ( ou borbulhe do seu ponto atual, potencialmente até o usuário) saiba que não há absolutamente nenhuma maneira de um componente específico funcionar sob as condições atuais e que não é possível recuperar sem algum tipo de intervenção externa (outro módulo ou usuário) .


1

Não temos regras de manipulação de exceções específicas para nossa equipe, exceto as usuais: não use exceções para o comportamento 'normal', não apenas aceite exceções silenciosamente, etc.

A análise estática pode ajudá-lo a capturar alguns deles (dependendo do idioma usado), mas você ficará mais seguro com as revisões de código.


1

Atualmente, não temos diretrizes explícitas, principalmente porque ninguém na minha equipe faz errado. (Ao contrário de muitos outros tópicos, existe um consenso geral quando e como as exceções devem ser usadas)

Mas eu definitivamente os implementaria no mesmo dia em que vejo uma exceção abusada como um goto.


0

Eu acho que as exceções devem reagir às exceções. Eu acho que é abusivo e gera sobrecarga ao usar exceções como um fluxo de trabalho no seu código. Portanto, mantenha-os detalhados e use somente quando algo inesperado aconteceu.

Nota: bandeja para evitar os erros mais comuns, como não passar o banco de dados de conexão para uma função ou coisas assim. Mas use-os quando o primaryKey não existir e você precisar fazer algo.


0

Sinto muito por você ter herdado o código de pessoas que abusam de exceções para serem declarações do tipo goto.

Eu sempre tento capturá-los quando qualquer entrada do usuário ou algo fora do meu controle pode acontecer (ex: IOExceptions), mas qualquer coisa que possa ser um erro de codificação (ex: NullPointerException) é algo que eu tentaria capturar com afirmações no início do desenvolvimento.

O desempenho atingido com esse tipo de codificação é um enorme negativo. Gostaria de saber se a empresa estava encolhendo devido a desenvolvedores terríveis se metendo em uma confusão além da compreensão ...

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.