A mensagem de erro que ninguém lê até o fim

A frase "Is a directory" aparece sozinha na ponta da linha, em letra de máquina de escrever, logo depois de um rm fotos digitado com a confiança de quem já fez aquilo centenas de vezes. A linha inteira diz rm: cannot remove 'fotos': Is a directory, e muita gente sente diante dela o mesmo arrepio de quem recebe carta registrada do cartório. Só depois de alguns segundos a pessoa repara que o computador fez uma observação bastante educada. Ele avisou que fotos é uma pasta, coisa que o dono sabia perfeitamente, e que o rm sem a opção certa se recusa a apagar pastas. Acabou de salvar as fotos das férias. Merecia um agradecimento, e costuma ganhar um palavrão.

A mensagem de erro é, muito provavelmente, o texto em inglês que o profissional de tecnologia mais lê ao longo da vida, à frente da documentação e de qualquer romance prometido para as férias. É também o texto que ele lê com mais pressa. O olho bate na primeira palavra assustadora, e a mão já está copiando a linha para o buscador antes que a leitura chegue ao último termo. Pois é. A gente trata o recado do sistema como alarme de incêndio, quando na maioria das vezes ele se parece bem mais com um bilhete preso na geladeira.

Quem escreve essas mensagens é, quase sempre, um programador que precisava caber numa linha e tinha pressa de voltar ao que estava fazendo. O resultado é um inglês com gramática própria, econômico até a avareza, parecido com o das manchetes de jornal. O artigo desaparece, e o verbo auxiliar costuma ir embora com ele. "Permission denied" quer dizer "a permissão foi negada", e o "was" ficou para trás como quem corta caminho pelo estacionamento. O brasileiro conhece esse idioma melhor do que imagina, porque lê manchetes em português escritas exatamente assim desde que aprendeu a ler.

Tome o bash: sl: command not found, provavelmente a mensagem mais democrática do Unix. A frase completa seria "the command was not found", e o shell está contando que procurou nos lugares onde costuma guardar programas e voltou de mãos vazias. Na imensa maioria dos casos o comando existe no mundo e mora longe dali, ou então o dedo trocou a ordem das letras de ls. A mensagem, convenhamos, sai muito mais gentil que a nossa reação a ela. Ela relata uma busca malsucedida com a serenidade de um bibliotecário, e o usuário responde com a indignação de quem foi acusado de um crime.

Existem palavras, porém, que merecem atenção especial, porque enganam justamente quem acha que entendeu. "Deprecated" é a campeã. O olho brasileiro vê ali o "depreciado" da contabilidade, o carro que perde valor ao sair da concessionária, e conclui que a função ficou velha e meio desvalorizada. A ideia chega perto, e o sentido técnico vai além dela. Uma função deprecated continua funcionando hoje, só que os autores desaconselham o uso e já avisaram que ela vai embora numa versão futura.

O paralelo mais honesto que encontro é o do funcionário que recebeu aviso prévio. Ele segue chegando no horário e entregando o trabalho, e todo mundo no escritório já sabe que a mesa dele vai ficar vazia daqui a pouco. Quem ignora o aviso descobre o problema na atualização seguinte, quando a função some de vez e o sistema para numa sexta-feira à tarde. O aviso estava ali havia meses, impresso no terminal de todo mundo, e foi lido com a mesma atenção que a gente dedica aos termos de uso. Acredite. A versão nova cumpre a ameaça com uma pontualidade de relógio suíço.

"Deadlock" vem de outra família, e a tradução literal ajuda pouco. Juntar "dead" e "lock" dá alguma coisa como "tranca morta", expressão que parece título de romance policial de banca de jornal. No mundo dos sistemas, o deadlock acontece quando dois processos ficam presos esperando um pelo outro. Cada um segura um recurso de que o outro precisa e se recusa a soltá-lo antes de receber o que pediu. Os dois esperam para sempre, com a mesma determinação.

A imagem que resolve o termo de uma vez é a dos dois motoristas educados numa ponte de mão única, cada um parado numa cabeceira, esperando que o outro dê ré primeiro. Ninguém está errado, e o trânsito fica parado até que alguém de fora intervenha. O banco de dados faz exatamente esse papel de guarda de trânsito quando detecta a situação: cancela a operação de um dos processos e manda o outro seguir. O escolhido recebe a notícia em inglês, claro, e quem lê o log na manhã seguinte precisa entender que houve ali um empate técnico de boas maneiras, sem defeito de parte alguma.

Se o deadlock nasce do excesso de educação, a "race condition" nasce da falta dela, e pede ainda mais cuidado, embora a tradução oficial, "condição de corrida", esteja correta. A palavra "corrida" sugere velocidade, e o termo descreve um resultado que depende de quem chega primeiro, quando dois processos mexem no mesmo dado quase ao mesmo tempo. Na maior parte das vezes a ordem sai certa e tudo funciona. De vez em quando a ordem se inverte e o resultado sai errado, sem que ninguém tenha mudado uma linha de código.

É o defeito mais traiçoeiro que existe, porque some quando alguém tenta observá-lo de perto. Basta o programador colocar uma mensagem de depuração para entender o que acontece: ela atrasa um dos processos em uma fração de segundo, e a corrida passa a terminar sempre na ordem certa. O sistema funciona perfeitamente enquanto está sendo vigiado e volta a falhar assim que a vigilância vai embora. Lembra goteira que some no dia em que o encanador vem ver. Aliás, é certeza: quem já caçou um desses fala de race condition com o mesmo respeito com que pescador fala do peixe que escapou.

Há ainda um capítulo do vocabulário de log que merece ser lido em voz alta, de preferência com trilha sonora. O Linux, quando a memória acaba, aciona um mecanismo chamado OOM killer, sigla de "out of memory" seguida de uma palavra que dispensa tradução. Ele encerra um processo para salvar o resto do sistema e registra o ocorrido com o verbo "kill", sem a menor cerimônia. O vocabulário segue nesse tom por toda parte, com processos "killed" e erros "fatal". Quem lê o registro sem preparo acha que o servidor passou a noite envolvido num caso de polícia.

A joia da coleção é o "kernel panic". O núcleo do sistema operacional encontrou um erro grave demais para seguir com segurança e decidiu parar tudo antes de causar estrago maior. Foi uma decisão sensata, quase heroica, tomada por um pedaço de software que preferiu cair a corromper os dados de alguém. O nome, contudo, sugere outra coisa. O núcleo do sistema entrou em pânico, e o operador, por solidariedade, entrou também. Simples assim.

Essa dramaticidade toda esconde uma lição útil para quem estuda inglês. As palavras do log são fortes porque precisam chamar a atenção de alguém que está ocupado com outra coisa, exatamente como as manchetes. Quem aprende a calibrar o susto, separando o "warning" do "fatal", passa a ler o terminal como um leitor experiente lê o jornal. Ele vai direto ao que interessa e deixa o tom da manchete por conta do editor. O "warning", vale dizer, é o primo mais novo do "deprecated": avisa hoje sobre o problema de amanhã, e quase sempre é ignorado com o mesmo entusiasmo.

O hábito que mais rende, e que custa apenas alguns segundos de atenção, é ler a mensagem até o fim. O inglês dos erros costuma colocar o nome de quem reclama no começo da linha e o motivo da reclamação lá no final, depois dos últimos dois-pontos. Em bash: cd: /etc/app: No such file or directory, a parte assustadora fica na frente e a explicação inteira mora nas palavras finais. Elas dizem, com toda a clareza, que a pasta procurada simplesmente não existe naquele endereço. Quem lê só o começo enxerga um problema, e quem chega ao fim encontra a resposta.

Se você parar para pensar, é o mesmo cuidado que a gente aprende a ter com contrato de aluguel. A cláusula importante raramente está no primeiro parágrafo, e o leitor apressado assina tudo sem saber que se comprometeu a pintar o apartamento de branco na saída. A mensagem de erro é um contrato curtinho, de uma linha só, e mesmo assim muita gente assina sem ler. Depois reclama com o síndico, que no caso é o colega mais experiente da equipe, aquele que lê a linha em voz alta e resolve o mistério sem tocar no teclado.

A busca na internet, por sua vez, funciona muito bem com mensagens de erro, e por uma razão que tem tudo a ver com idioma. A frase em inglês é idêntica para todo mundo que já tropeçou no mesmo problema, em qualquer país, e por isso abre a porta de fóruns inteiros com a precisão de uma chave. O cuidado está em separar a parte genérica da parte que é sua. O nome da pasta e o caminho do arquivo pertencem ao seu computador e atrapalham a busca, enquanto o restante da frase pertence ao mundo. Saber fazer essa separação já é um exercício de leitura em inglês, e dos bons.

Hoje existe ainda a opção de colar o erro numa ferramenta de inteligência artificial e pedir uma explicação. É um recurso valioso, desde que a explicação seja tratada como aula e deixe alguma coisa para trás. A ferramenta explica com paciência infinita o que é um deadlock, e a pessoa que só copia a solução volta a perguntar a mesma coisa na semana seguinte, com a mesma cara de surpresa. Quem lê a explicação com atenção, ao contrário, ganha uma palavra nova para sempre. A muleta ajuda a andar enquanto a perna se recupera, e o problema começa quando ela vira a perna.

Existe um mérito pedagógico nas mensagens de erro que poucos professores de inglês poderiam reproduzir em sala de aula. Elas chegam sempre acompanhadas de um contexto que o leitor conhece intimamente, porque foi ele mesmo quem digitou o comando, e carregam uma consequência imediata, já que entender a frase significa colocar o sistema para funcionar de novo. Poucas situações de aprendizado reúnem tanta motivação. O servidor fora do ar, convenhamos, é um professor particular de uma eficiência assustadora.

O exercício que proponho cabe em qualquer rotina e dispensa material didático. Na próxima vez que o terminal reclamar de alguma coisa, leia a linha devagar e inteira, à caça do verbo, mesmo quando ele estiver escondido num particípio solitário. Antes de qualquer busca, tente dizer em português, com suas palavras, o que o sistema tentou fazer e por que desistiu. Na maioria das vezes a resposta já estava ali. Nas outras, a busca que vem depois fica muito mais precisa, porque a pessoa já sabe o que está procurando.

Há também o dia, mais cedo ou mais tarde, em que o profissional passa para o outro lado e começa a escrever as próprias mensagens de erro, num script que alguém vai rodar quando ele estiver de férias. Esse é o melhor teste de inglês que conheço. A mensagem precisa dizer o que falhou e onde, em poucas palavras, para um leitor que pode estar em outro fuso horário e com o mesmo coração acelerado. Quem já penou para decifrar o recado alheio costuma escrever o próprio com bem mais caridade, e o colega do outro fuso agradece sem saber a quem.

O computador escreve para a gente em inglês desde muito antes de qualquer aplicativo de idiomas existir, e escreve com uma paciência que nenhum correspondente humano teria. Repete a mesma carta quantas vezes for preciso, sem mudar uma vírgula e sem perder a educação, e espera apenas que alguém a leia até a assinatura. Quem passa a ler essas cartas com calma descobre que o remetente quase sempre tinha razão, e que o susto nasceu da pressa do destinatário. É um correspondente fiel, um pouco seco no estilo, que só levanta a voz quando o núcleo entra em pânico, e mesmo assim avisa antes.

PS: Conte nos comentários qual mensagem de erro já fez você suar frio antes de ler até o fim, e compartilhe este texto com aquele colega que cola tudo no buscador sem ler a linha. O buscador agradece pelos dois, e o colega, quem sabe, agradece um dia.