A declaração de retorno ausente em um método não nulo compila

Eu encontrei uma situação em que um método não nulo está faltando uma instrução de retorno e o código ainda é compilado. Eu sei que as instruções após o loop while são inacessíveis (código morto) e nunca seriam executadas. Mas por que o compilador nem avisa sobre o retorno de algo? Ou por que uma linguagem nos permitiria ter um método não vazio com um loop infinito e não retornando nada?

public int doNotReturnAnything() {
    while(true) {
        //do something
    }
    //no return statement
}

Se eu adicionar uma instrução break (mesmo que condicional) no loop while, o compilador reclamará dos erros infames: Method does not return a valueno Eclipse e Not all code paths return a valueno Visual Studio.

public int doNotReturnAnything() {
    while(true) {
        if(mustReturn) break;
        //do something
    }
    //no return statement
}

Isso vale para Java e C #.

Por que uma linguagem nos permite ter um método não nulo com um loop infinito e sem retornar nada?

A regra para métodos não nulos é todo caminho de código retornado deve retornar um valor , e essa regra é satisfeita no seu programa: zero dos zero caminhos de código retornados retornam um valor. A regra não é "todo método não nulo deve ter um caminho de código que retorne".

Isso permite que você escreva métodos stub como:

IEnumerator IEnumerable.GetEnumerator() 
{ 
    throw new NotImplementedException(); 
}

Esse é um método não vazio. Ele tem de ser um método não-nula, a fim de satisfazer a interface. Mas parece bobagem tornar essa implementação ilegal porque ela não retorna nada.

O fato de seu método ter um ponto final inacessível por causa de um goto(lembre-se, a while(true)é apenas uma maneira mais agradável de escrever goto) em vez de um throw(que é outra forma de goto) não é relevante.

Por que o compilador nem avisa sobre o retorno de algo?

Porque o compilador não tem boas evidências de que o código esteja errado. Alguém escreveu while(true)e parece provável que a pessoa que fez isso sabia o que estava fazendo.

Onde posso ler mais sobre a análise de acessibilidade em C #?

Veja meus artigos sobre o assunto, aqui:

ATBG: acessibilidade de fato e de jure

E você também pode considerar ler a especificação C #.

O compilador Java é inteligente o suficiente para encontrar o código inacessível (o código após o whileloop)

e, como é inacessível , não faz sentido adicionar uma returndeclaração lá (após o whiletérmino)

o mesmo acontece com condicional if

public int get() {
   if(someBoolean) {   
     return 10;
   }
   else {
     return 5;
   }
   // there is no need of say, return 11 here;
}

como a condição booleana someBooleansó pode ser avaliada como uma trueou outra false, não há necessidade de fornecer uma após return explicitamenteif-else , porque esse código é inacessível e o Java não se queixa.

O compilador sabe que o whileloop nunca irá parar de executar; portanto, o método nunca será concluído; portanto, uma returninstrução não é necessária.

Dado que seu loop está sendo executado em uma constante - o compilador sabe que é um loop infinito - o que significa que o método nunca poderia retornar.

Se você usar uma variável - o compilador aplicará a regra:

Isso não será compilado:

// Define other methods and classes here
public int doNotReturnAnything() {
    var x = true;

    while(x == true) {
        //do something
    }
    //no return statement - won't compile
}

A especificação Java define um conceito chamado Unreachable statements. Você não tem permissão para ter uma instrução inacessível no seu código (é um erro de tempo de compilação). Você não tem permissão para ter uma declaração de retorno depois de um tempo (true); declaração em Java. Uma while(true);instrução torna as seguintes instruções inacessíveis por definição; portanto, você não precisa de umreturn instrução.

Observe que, embora o problema de parada seja indecidível em casos genéricos, a definição de Instrução inacessível é mais rigorosa do que apenas parar. Está decidindo casos muito específicos em que um programa definitivamente não é interrompido. Teoricamente, o compilador não é capaz de detectar todos os loops infinitos e instruções inacessíveis, mas precisa detectar casos específicos definidos na especificação (por exemplo, o while(true)caso)

O compilador é inteligente o suficiente para descobrir que seu while loop é infinito.

Portanto, o compilador não pode pensar em você. Não dá para adivinhar por que você escreveu esse código. O mesmo vale para os valores de retorno dos métodos. Java não vai reclamar se você não fizer nada com os valores de retorno do método.

Então, para responder sua pergunta:

O compilador analisa seu código e, depois de descobrir que nenhum caminho de execução leva a cair no final da função, ele termina com OK.

Pode haver razões legítimas para um loop infinito. Por exemplo, muitos aplicativos usam um loop principal infinito. Outro exemplo é um servidor web que pode esperar indefinidamente por solicitações.

Na teoria dos tipos, existe algo chamado tipo inferior que é uma subclasse de qualquer outro tipo (!) E é usado para indicar não terminação, entre outras coisas. (Exceções podem contar como um tipo de não-rescisão - você não termina pelo caminho normal.)

Portanto, de uma perspectiva teórica, pode-se considerar que essas declarações que não terminam retornam algo do tipo Bottom, que é um subtipo de int, para que você (tipo de) obtenha seu valor de retorno, afinal, de uma perspectiva de tipo. E é perfeitamente aceitável que não faça sentido que um tipo possa ser uma subclasse de todo o resto, incluindo int, porque você nunca retorna um.

De qualquer forma, por meio da teoria explícita dos tipos ou não, os compiladores (escritores do compilador) reconhecem que solicitar um valor de retorno após uma declaração não-terminante é tolo: não há um caso possível em que você possa precisar desse valor. (Pode ser bom ter o seu compilador avisando quando algo não terminar, mas parece que você deseja retornar algo. Mas isso é melhor para os verificadores de estilo a la lint, pois talvez você precise da assinatura de tipo que por algum outro motivo (por exemplo, subclassificação), mas você realmente deseja não rescisão.)

Não há situação em que a função possa chegar ao fim sem retornar um valor apropriado. Portanto, não há nada para o compilador reclamar.

O Visual Studio possui o mecanismo inteligente para detectar se você digitou um tipo de retorno, e deve ter uma instrução de retorno na função / método

Como no PHP Seu tipo de retorno é verdadeiro se você não retornou nada. compilador obter 1 se nada tiver retornado.

A partir deste

public int doNotReturnAnything() {
    while(true) {
        //do something
    }
    //no return statement
}

O compilador sabe que a declaração while possui uma natureza infinita, portanto, não deve ser considerada. O compilador php será automaticamente verdadeiro se você escrever uma condição na expressão while.

Mas não no caso do VS, ele retornará um erro na pilha.

Seu loop while funcionará para sempre e, portanto, não sairá enquanto; continuará sendo executado. Portanto, a parte externa de while {} está inacessível e não faz sentido escrever ou não retornar. O compilador é inteligente o suficiente para descobrir qual parte é alcançável e qual não é.

Exemplo:

public int xyz(){
    boolean x=true;

    while(x==true){
        // do something  
    }

    // no return statement
}

O código acima não será compilado, porque pode haver um caso em que o valor da variável x seja modificado dentro do corpo do loop while. Portanto, isso torna a parte externa do loop while acessível! E, portanto, o compilador lançará um erro 'nenhuma declaração de retorno encontrada'.

O compilador não é inteligente o suficiente (ou melhor, preguiçoso;)) para descobrir se o valor de x será modificado ou não. Espero que isso limpe tudo.

"Por que o compilador nem avisa sobre o retorno de algo? Ou por que uma linguagem nos permite ter um método não vazio com um loop infinito e sem retornar nada?".

Este código também é válido em todos os outros idiomas (provavelmente exceto Haskell!). Como a primeira suposição é que estamos "intencionalmente" escrevendo algum código.

E há situações em que esse código pode ser totalmente válido, como se você fosse usá-lo como um encadeamento; ou se estava retornando a Task<int>, você poderia fazer alguma verificação de erro com base no valor int retornado - que não deve ser retornado.

Posso estar errado, mas alguns depuradores permitem a modificação de variáveis. Aqui, enquanto x não é modificado pelo código e será otimizado pelo JIT, pode-se modificar x para false e o método deve retornar algo (se isso for permitido pelo depurador de C #).

As especificidades do caso Java para isso (que provavelmente são muito semelhantes ao caso C #) têm a ver com a forma como o compilador Java determina se um método pode retornar.

Especificamente, as regras são que um método com um tipo de retorno não deve ser capaz de concluir normalmente e deve sempre ser concluído abruptamente (abruptamente aqui indicando por meio de uma declaração de retorno ou uma exceção) de acordo com o JLS 8.4.7 .

Se um método for declarado com um tipo de retorno, ocorrerá um erro em tempo de compilação se o corpo do método puder ser concluído normalmente. Em outras palavras, um método com um tipo de retorno deve retornar apenas usando uma instrução de retorno que forneça um retorno de valor; não é permitido "deixar cair o final do corpo" .

O compilador verifica se a terminação normal é possível com base nas regras definidas em Instruções inacessíveis do JLS 14.21 , pois também define as regras para a conclusão normal.

Notavelmente, as regras para instruções inacessíveis formam um caso especial apenas para loops que possuem uma trueexpressão constante definida :

Uma instrução while pode ser concluída normalmente se pelo menos um dos seguintes for verdadeiro:

• A instrução while é alcançável e a expressão da condição não é uma expressão constante (§15.28) com o valor true.

• Há uma instrução de quebra acessível que sai da instrução while.

Portanto, se a whileinstrução puder ser concluída normalmente , será necessária uma instrução de retorno abaixo dela, pois o código é considerado acessível e qualquer whileloop sem uma instrução de quebra acessível ou constantetrue expressão é considerado capaz de ser concluído normalmente.

Essas regras significam que sua whiledeclaração com uma expressão verdadeira constante e sem a nuncabreak é considerada concluída normalmente e, portanto, qualquer código abaixo dela nunca é considerado alcançável . O final do método está abaixo do loop, e como tudo abaixo do loop é inacessível, o mesmo ocorre com o final do método e, portanto, o método não pode ser concluído normalmente normalmente (que é o que o complier procura).

if as instruções, por outro lado, não têm a isenção especial em relação às expressões constantes que são oferecidas aos loops.

Comparar:

// I have a compiler error!
public boolean testReturn()
{
    final boolean condition = true;

    if (condition) return true;
}

Com:

// I compile just fine!
public boolean testReturn()
{
    final boolean condition = true;

    while (condition)
    {
        return true;
    }
}

O motivo da distinção é bastante interessante e se deve ao desejo de permitir sinalizadores de compilação condicionais que não causam erros do compilador (do JLS):

Pode-se esperar que a instrução if seja tratada da seguinte maneira:

• Uma instrução if-then pode ser concluída normalmente se pelo menos uma das seguintes opções for verdadeira:

  • A instrução if-then é alcançável e a expressão da condição não é uma expressão constante cujo valor é verdadeiro.

  • A declaração then pode ser concluída normalmente.

  A instrução then é alcançável se a instrução if-then é alcançável e a expressão de condição não é uma expressão constante cujo valor é falso.

• Uma instrução if-then-else pode ser concluída normalmente se a instrução then pode ser concluída normalmente ou a instrução else pode ser concluída normalmente.

  • A instrução then é alcançável se a instrução if-then-else for alcançável e a expressão da condição não for uma expressão constante cujo valor for falso.

  • A instrução else é alcançável se a instrução if-then-else for alcançável e a expressão da condição não for uma expressão constante cujo valor for verdadeiro.

Essa abordagem seria consistente com o tratamento de outras estruturas de controle. No entanto, para permitir que a instrução if seja usada convenientemente para fins de "compilação condicional", as regras reais diferem.

Como exemplo, a seguinte instrução resulta em um erro em tempo de compilação:

while (false) { x=3; }porque a afirmação x=3;não é alcançável; mas o caso superficialmente semelhante:

if (false) { x=3; }não resulta em um erro em tempo de compilação. Um compilador otimizador pode perceber que a instrução x=3;nunca será executada e pode optar por omitir o código dessa instrução do arquivo de classe gerado, mas a instruçãox=3; não é considerada "inacessível" no sentido técnico especificado aqui.

A lógica desse tratamento diferente é permitir que os programadores definam "variáveis ​​de flag", como:

static final boolean DEBUG = false; e escreva um código como:

if (DEBUG) { x=3; } A idéia é que seja possível alterar o valor de DEBUG de falso para verdadeiro ou de verdadeiro para falso e compilar o código corretamente, sem outras alterações no texto do programa.

Por que a instrução de interrupção condicional resulta em um erro do compilador?

Conforme citado nas regras de alcançabilidade do loop, um loop while também pode ser concluído normalmente se contiver uma instrução de interrupção acessível. Como as regras para a acessibilidade da cláusula then de uma ifinstrução não levam em consideração a condição da condição , essa declaração condicional é entãoifif cláusula cláusula é sempre considerada alcançável.

Se breakestiver acessível, o código após o loop será novamente considerado acessível. Como não há código acessível que resulte em término abrupto após o loop, o método é considerado capaz de ser concluído normalmente e, portanto, o compilador o sinaliza como erro.