Em um material escrito por Igor Kulakov, a JetBrains apresenta um guia prático para usar Logpoints no IntelliJ IDEA 2026.2 para diagnosticar erros em aplicações Java durante a execução. A ideia é semelhante a adicionar instruções println ao programa, mas sem modificar o código, reconstruir a aplicação ou implantá-la novamente, e o processo também não interrompe a execução. Isso torna o recurso adequado para inspecionar serviços executados localmente, dentro de um contêiner Docker ou em um host remoto.
O problema abordado pelo exemplo
O exemplo usa um cliente e um servidor que se comunicam por gRPC. O servidor retorna um valor de desconto incorreto para alguns locatários. Ao enviar uma solicitação para o locatário JetBrains e a região EMEA, o console exibe um preço de 100,00 dólares com discount_bps=0, enquanto o valor esperado é 80,00 dólares com discount_bps=2000.
O servidor é executado usando Docker, com as portas de escuta e a depuração expostas, e o cliente envia solicitações periodicamente. Depois de iniciar o servidor e o cliente, o desenvolvedor pode anexar o depurador do IntelliJ IDEA ao processo, mesmo que ele não tenha sido iniciado em uma sessão de depuração local. Segundo a explicação, o depurador se comunica por meio de um socket em cenários locais, ambientes separados e hosts remotos; portanto, o princípio de anexar-se não muda conforme o local em que o processo Java é executado.
Como os Logpoints revelam a causa do erro?
No IntelliJ IDEA 2026.2, é possível criar um Logpoint rapidamente clicando na margem do editor entre duas linhas executáveis e inserindo a expressão que se deseja registrar. O desenvolvedor começa registrando informações do início do processamento da solicitação e, em seguida, adiciona ou modifica os pontos gradualmente enquanto as solicitações continuam chegando.
O rastreamento da cadeia de chamadas leva à função discountBpsFor(). As saídas revelam que o nome do locatário chega como JetBrains, enquanto a lógica de comparação espera o valor jetbrains. As saídas também mostram que o desconto não foi aplicado, o que significa que o ramo do código que retorna o valor de 2.000 pontos-base não foi executado. O exemplo sugere corrigir a comparação usando equalsIgnoreCase e, em seguida, testar o comportamento esperado.
O benefício não se limita à exibição do texto no console; ao clicar em uma linha da saída, o IntelliJ IDEA pode navegar até o Logpoint ou até a parte do código relacionada a ele. Essa navegação também funciona com instruções println quando o processo está sendo executado sob o depurador do IntelliJ IDEA.
Quando eles são melhores do que println e pontos de interrupção?
O material explica que os Logpoints não poluem o código nem deixam para trás instruções de depuração que possam ser enviadas acidentalmente para um ambiente de produção. Também é possível alterar o que é registrado e quando isso é feito, incluindo a amostragem de eventos repetidos, a adição de registros dentro de dependências e a prevenção de reimplantações dispendiosas.
Já os pontos de interrupção tradicionais podem ser inadequados quando interromper o serviço faz parte do problema. No exemplo, o cliente define um tempo limite para uma solicitação gRPC, e esse tempo limite pode ser transmitido ao servidor. Quando o depurador interrompe o servidor, o tempo limite expira e a solicitação passa para o caminho de cancelamento; assim, o desenvolvedor deixa de ver o estado que levou ao erro. Nesse caso, o uso de um ponto de interrupção exige o envio sequencial das solicitações e o trabalho dentro da janela de tempo limite.
Em contraste, os Logpoints fornecem informações sem suspender o servidor, permitindo monitorar as solicitações enquanto são executadas e evitar a ativação do caminho de cancelamento causado pelo vencimento do tempo limite.
Modificar temporariamente o comportamento durante a execução
O material também usa Logpoints para testar temporariamente o efeito de uma correção ou de uma alteração no comportamento do programa, com o alerta de que eles foram projetados principalmente para registro, não para modificar a aplicação. Usando expressões com efeitos colaterais, é possível alterar o valor do tempo limite dentro da biblioteca gRPC durante a execução. O exemplo mostra a alteração de timeoutNanos para um tempo limite de cinco minutos.
Para reduzir o impacto dessa alteração, é possível restringi-la às solicitações que contenham um cabeçalho Debug, mantendo o tempo limite normal para as demais solicitações. O exemplo inclui uma lógica de várias linhas que lê o cabeçalho e redefine o tempo limite somente quando seu valor corresponde, exibindo em seguida a mensagem Timeout reset para confirmar que o ramo foi visitado.
Com o que é preciso ter cuidado?
A JetBrains alerta contra a inclusão de cálculos pesados em caminhos críticos, pois as expressões de registro são executadas dentro da própria máquina virtual e não são gratuitas em termos de tempo. A empresa observa que o IntelliJ IDEA 2026.2 remove a sobrecarga causada pelo depurador por meio de instrumentation, mas isso não elimina o custo das expressões nem do registro intenso.
O material também menciona a possibilidade de usar o recurso Mark Object para acessar objetos arbitrários a partir do campo de expressão de um Logpoint, além da habilidade de agente de IA ij-debugger incluída, que pode identificar onde o tempo limite é lido e criar uma expressão direcionada às solicitações de teste. Esse caminho continua sendo uma alternativa à compreensão manual, não uma prova de que a alteração temporária é segura para todos os ambientes.
A leitura editorial de certi.news
O valor prático aqui não está em adicionar um novo tipo de mensagem de registro, mas em transferir o diagnóstico para uma camada que pode ser modificada durante a execução. Isso é especialmente importante para serviços remotos ou sujeitos a condições de corrida ou tempos limite, nos quais interromper a execução pode ocultar o próprio problema. Por outro lado, a abordagem exige disciplina na escolha das expressões e no monitoramento de seu custo; além disso, o uso de efeitos colaterais para modificar o comportamento deve permanecer restrito a cenários de depuração claros e temporários, e não se transformar em uma alternativa à correção do código-fonte.