Alternativa B - Continuar a análise após realizar a recuperação do erro e anotá-lo para informação posterior.
Fundamentação Teórica
No contexto da construção de compiladores, o processo de análise léxica (ou scanning) é a primeira fase. O objetivo principal é transformar o código-fonte em uma sequência de tokens (unidades significativas).
Quando o scanner encontra um padrão que não corresponde a nenhum token válido (um erro léxico, como um caractere desconhecido), ele precisa adotar uma estratégia de recuperação de erros.
Por que a Alternativa B é correta?
Compiladores modernos buscam ser robustos e fornecer feedback completo ao programador. Se o scanner parasse imediatamente na primeira falha (Alternativa A), o usuário teria que corrigir um erro por vez, o que é ineficiente.
A abordagem ideal envolve:
- Detecção: Identificar que o padrão não é válido.
- Recuperação: Tentar avançar no fluxo de leitura para encontrar o próximo ponto de sincronização (por exemplo, pular caracteres inválidos até encontrar um separador conhecido).
- Registro: Anotar o erro encontrado para gerar mensagens de diagnóstico ao final ou durante o processo.
- Continuidade: Permitir que a análise continue para encontrar outros erros subsequentes.
Análise das outras alternativas
| Alternativa | Avaliação | Motivo |
|---|
| A | Incorreta | Parar imediatamente impede a detecção de múltiplos erros no mesmo arquivo. |
| C | Incorreta | Ignorar totalmente significa que o erro nunca será comunicado ao desenvolvedor. |
| D | Incorreta | O scanner não tem autonomia para "reescrever" permanentemente o código fonte sem intervenção humana; sua função é analisar, não editar. |
Conclusão
A estratégia de recuperação de erros com continuação da análise é o padrão da indústria para garantir usabilidade e eficiência na compilação. Portanto, a alternativa B descreve corretamente o comportamento esperado de um analisador léxico robusto.