Interruptor sem pausa

Eu tenho algumas instruções switch como mostrado abaixo. Observe que não há pausa. Findbugs está relatando erro na segunda instrução de caso apenas. O erro é: Instrução switch encontrada onde um caso passa para o próximo caso.

switch(x) { case 0: // code case 1: // code case 2: // code } 

Findbugs está sinalizando que cair de um case para o outro geralmente não é uma boa idéia se existe algum código no primeiro (embora às vezes possa ser usado com bons resultados). Então, quando ele vê o segundo case e não break , ele relata o erro.

Então, por exemplo:

 switch (foo) { case 0: doSomething(); case 1: doSomethingElse(); default: doSomeOtherThing(); } 

Este é um Java perfeitamente válido, mas provavelmente não faz o que o autor pretendia: Se foo for 0 , todas as três funções doSomething , doSomethingElse e doSomeOtherThing executadas (nessa ordem). Se foo for 1 , somente doSomethingElse e doSomeOtherThing executados. Se foo for qualquer outro valor, somente doSomeOtherThing executado.

Em contraste:

 switch (foo) { case 0: doSomething(); break; case 1: doSomethingElse(); break; default: doSomeOtherThing(); break; } 

Aqui, apenas uma das funções será executada, dependendo do valor de foo .

Como é um erro comum de codificação esquecer o break , ferramentas como o Findbugs sinalizam para você.

Há um caso de uso comum em que você tem várias instruções de case em uma linha sem nenhum código intermediário:

 switch (foo) { case 0: case 1: doSomething(); break; case 2: doSomethingElse(); break; default: doSomeOtherThing(); break; } 

Lá, queremos chamar doSomething se foo for 0 ou 1 . A maioria das ferramentas não sinaliza isso como um possível erro de codificação, porque não há código no case 0 anterior ao case 1 e esse é um padrão bastante comum.

Eu escrevi estes como comentários, mas depois não é visível. Estou transformando-os em uma resposta. Esta é realmente uma extensão da resposta de TJCrowder .

Você pode encontrar a regra relacionada que faz com que o Findbugs relate um erro aqui .

Você pode impedir que o Findbugs relate esse tipo de erro criando um arquivo xml com o seguinte conteúdo, digamos, filter.xml e executando a ferramenta com a opção -exclude filter.xml . Veja os filtros no Findbugs .

      

Switch-throughs caem sob a categoria Findbugs de “código desonesto”. Eu acho que apenas sinaliza a primeira ocorrência de um fall-through em uma instrução switch para reduzir o número de mensagens de erro.

Sem o intervalo, eles irão cair um no outro, portanto, se x == 0 você passará por todo o código em cada bloco de instrução de caso. Findbugs pode estar errado sobre o erro, ou pode ser uma condição de erro sem a quebra, ou seja, algo no case 0 faz com que algo no case 1 seja interrompido.

Sem o código e erro exatos, não posso realmente ajudar mais. A falta de pausas é deliberada?

Normalmente, as ferramentas de análise de erros não gostam de passar por código porque, na maioria dos casos, o usuário acaba de esquecer de escrever a quebra.

Não sei se existe uma maneira de desativar especificamente o aviso com FindBugs, mas a ferramenta Checkstyle reconhece comentários especiais como / * fallthrough * / para assumir que o usuário realmente deseja que o código a seguir seja executado. Colocar esse tipo de comentário também melhora a legibilidade. http://checkstyle.sourceforge.net/config_coding.html#FallThrough

A convenção de código Java também menciona o uso do comentário de queda. http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html

Se os seus casos não tiverem rompimento, uma vez que um caso seja acionado, o interruptor passará por todos os casos até encontrar uma quebra ou o fim dos casos. Se você tiver o caso padrão, ele será acionado se o valor do seu comutador neste caso foo não corresponder a nenhum outro caso.