Como C# está tentando superar um equívoco de (muito mais que) um bilhão de dólares

Tony Hoare, em uma palestra na Qcon 2009 de Londres, reconheceu ter cometido um grande equívoco, há mais de 50 anos, projetando a capacidade de variáveis, de um determinado tipo, terem valor nulo, e, ao serem “desreferenciadas”, gerarem um valor especial indicando essa nulidade. Em C#, esse valor especial é null.

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. – Tony Hoare

O problema é que é fácil escrever programas de computador ignorando a possível nulidade de uma variável. Em .NET, quando isso ocorre, há uma interrupção da capacidade do programa seguir seu fluxo padrão ocasionando uma exceção – NullReferenceException. Sem dúvidas, uma dos erros mais comuns em tempo de execução e, por isso, uma fonte gigantesca de custos.

Há tempos, analisadores estáticos tem conseguido identificar e indicar trechos de código que ignoram a possibilidade de nulidade ao desreferenciar variáveis indicando, inclusive, práticas de programação defensiva que impediriam a ocorrência de NullReferenceException. Entretanto, a adoção desses analisadores ainda é bem baixa.

Recentemente, o time de design de linguagens da Microsoft responsável pelo C#, que desde o início suporta o conceito de nulidade em suas referências, resolveu tentar ajudar a conter prejuízos causados. Para isso, introduziu uma mudança de sintaxe que aumenta a expressividade do código e ajuda o compilador a detectar falhas deixando a linguagem um pouco mais complexa.

Fundamentalmente, a ideia é fazer com que o programador deixe “explícito” se o código que escreveu está preparado para lidar com a nulidade ou não.

public void Foo(Customer? c) // este método não terá problemas se c for nulo.
{
  if (c != null)
  {
    Console.WriteLine(c.Name);
  }
}

public void Fee(Customer c) // este método irá ter um "NullReferenceException" caso um nulo for passado.
{
  Console.WriteLine(c.Name)
}

Dessa forma, o compilador consegue ser inteligente o suficiente para detectar código que pode gerar instabilidade, gerando warnings no momento da compilação.

public Customer? GetCustomerById(string id)
{
  //..
}

No código acima, por exemplo, o método GetCustomerById deixa explícito que pode retornar um referência nula. Além disso, também está indicado que o método irá falhar, lançando uma exception, caso uma string nula seja passada como parâmetro. O compilador, então, tem condições de verificar se o retorno está sendo adequadamente tratado e se há chances de um valor nulo ser passado para o método, indicando reparação.

O problema, entretanto, é que esse conceito é novo e incompatível com o entendimento de código para C# até então. Um programador, embora experiente, que não esteja ambientado com essa mudança terá alguma dificuldade para entender o código e para produzir código novo em conformidade. Além disso, código escrito até aqui também não se encaixa nos critérios prescritos a partir de agora. Por isso, a adoção dessa característica é optativa e a Microsoft está tentando orquestrar o processo de adoção produzindo guias de orientação.

De qualquer forma, superadas as dores da adoção, uma das principais causas de erros em tempo de execução terá ficado para trás. É uma pena que essa feature não estivesse na especificação da linguagem desde sua primeira versão.

Em resumo

O problema
Em 1965, o Tony Hoare tomou uma decisão que impactou o futuro da computação definitivamente. Ele criou a capacidade de variáveis, de um determinado tipo, terem valor nulo. Essa é a causa de um dos erros mais comuns de tempo de execução com custos difíceis de calcular mas que, certamente, já ultrapassaram o montante de US$ 1.000.000.000,00.
A oportunidade
A Microsoft introduziu agora, no C#, uma feature que ajuda programadores a, provavelmente, eliminar os erros causados por variáveis com valores nulos. Trata-se de uma forma de deixar o código mais expressivo e que autoriza o compilador a detectar pontos sensíveis do código.
As ressalvas
Essa nova feature representa uma modificação conceitual profunda e, consequentemente, levará algum tempo até ser 100% aplicada pelas empresas e pelos fornecedores de componentes.

Compartilhe este insight:

Comentários

Participe deixando seu comentário sobre este artigo a seguir:

Subscribe
Notify of
guest
2 Comentários
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Vernizze
Vernizze
1 ano atrás

Elemar

Lendo esse seu post lembrou-me de um tutorial que havia em seu site falando de Monads.
Depois que o li, comecei a criar ‘safe methods’ abstratos, além de outros métodos de validação, como ‘.IsNull()’, .IsNotNull()’, para evitar que erros de NullReferenceException ocorressem. Desde essa época, lá por 2016, 2017 comecei a ter um cuidado maior que esse tipo de falha, que pode ser considerada até certo ponto como boba e que gera vários problemas e perdas.

Parabéns por trazer a nova info.

Diego
Diego
1 ano atrás

Não é algo novo, mas sem dúvida é extremamente essencial. A verificação de variáveis nulas são excelente para integridade do sistema, por isso tipos primitivos não aceitam nulos (com exceção do string).
É algo bem interessante de se ler, afinal, pouco se vê sobre isso.

AUTOR

Elemar Júnior
Fundador e CEO da EximiaCo atua como tech trusted advisor ajudando empresas a gerar mais resultados através da tecnologia.

SOLUÇÕES EXIMIACO

ESTRATÉGIA & EXECUÇÃO EM TI

Simplificamos, potencializamos 
aceleramos resultados usando a tecnologia do jeito certo.

COMO PODEMOS LHE AJUDAR?

Vamos marcar uma conversa para que possamos entender melhor sua situação e juntos avaliar de que forma a tecnologia pode trazer mais resultados para o seu negócio.

COMO PODEMOS LHE AJUDAR?

Vamos marcar uma conversa para que possamos entender melhor sua situação e juntos avaliar de que forma a tecnologia pode trazer mais resultados para o seu negócio.

+55 51 3049-7890 |  [email protected]

2
0
Queremos saber a sua opinião, deixe seu comentáriox
()
x

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

O seu insight foi excluído com sucesso!

O seu insight foi excluído e não está mais disponível.

O seu insight foi salvo com sucesso!

Ele está na fila de espera, aguardando ser revisado para ter sua publicação programada.