A maioria dos conjuntos de ferramentas de programação os oferece. Para alguns, é uma função de biblioteca como qualquer outra (como para C++ or C#), outros a integram em sua sintaxe ( Python, Java). Estou argumentando a favor de um estilo de programação que faça uso intenso de asserções (ou ferramentas mais poderosas, mas este não é o assunto por enquanto).
Asserções são
para tornar seu código seguro, expressando suposições . Digamos que você chame uma API cujo valor de retorno é um objeto que pode, de acordo com a documentação, não ser
null. Se forassertesse o caso, você não precisa se preocupar com isso novamente . Caso a API não esteja em conformidade com sua própria documentação (ou você a tenha interpretado incorretamente), a declaração será disparada. Proteger suas próprias suposições sobre o funcionamento do seu próprio código e do código de outras pessoas ajuda a detectar erros que, de outra forma, seriam terríveis de detectar. E as coisas sendonullou não são apenas o exemplo mais fácil de tal verificação.para documentar seu código . Suponha uma linguagem de programação que não possui referências de objeto que não podem ser
null. Se você tiver uma referência de objeto da qual sabe que não pode sernullse o resto do código estiver livre de erros, você deve afirmar que essa referência de objeto énon-null. Fazendo isso, você pode expressar essa invariante de forma mais concisa do que poderia com a documentação embutida e obter uma verificação de tempo de execução gratuitamente.uma maneira de distinguir claramente o erro de programação do erro de tempo de execução . Uma porta de rede não disponível é um erro de tempo de execução. No entanto, uma API chamada com um parâmetro inválido é um erro de programação, que (em um mundo ideal) não deveria precisar de nenhuma verificação de tempo de execução porque nunca é confiável para o fluxo de controle do programa! Java, por exemplo, é particularmente ruim nisso. levantar exceções de tempo de execução (não verificadas) para argumentos inválidos geralmente faz parte do contrato de um método e, portanto, a verificação não pode ser tecnicamente omitida. O que é detectado por essa construção em tempo de execução é geralmente um erro de programação, cuja presença indica um bugno software. As afirmações tornam isso muito claro. Se você falhar em uma asserção, você não vai contornar isso, exceto consertando seu código.
O principal motivo para bugs em software de computador é a incompatibilidade entre suas suposições sobre como algo se comportará e como realmente se comportará . Portanto, se você separar cuidadosamente suas próprias suposições sobre o funcionamento dos sistemas dos erros reais de tempo de execução e aprender como anotar suas suposições durante a codificação – por meio do uso de afirmações – poderá obter um software mais confiável. Um bom sinal é se, durante o teste, você raramente obtém travamentos em seu código, mas acaba em suas próprias afirmações.