Skip to main content

Command Palette

Search for a command to run...

3 erros comuns ao escrever procedures em PL/SQL (e como corrigir)

Updated
2 min read

Procedures são parte fundamental do desenvolvimento com PL/SQL — mas é comum ver códigos que, com o tempo, se tornam difíceis de entender, testar ou manter. Neste post, vou mostrar 3 erros comuns que vejo com frequência (e já cometi também), junto com soluções simples pra evitá-los.


Erro 1: Não isolar a lógica de negócio

É comum ver procedures que fazem "de tudo um pouco": validam dados, executam inserts, chamam outras procedures, retornam resultados... tudo junto.

Problema: Isso dificulta testes, manutenção e reaproveitamento.

Solução: Quebre a lógica em blocos reutilizáveis. Extraia validações para funções específicas, isole acessos ao banco quando possível.

-- Em vez de:
PROCEDURE processa_pedido(p_id IN NUMBER) IS
BEGIN
  IF p_id IS NULL THEN
    RAISE_APPLICATION_ERROR(-20001, 'ID inválido');
  END IF;
  -- lógica de negócio + insert + notificações etc...
END;

-- Faça:
FUNCTION valida_pedido(p_id IN NUMBER) RETURN BOOLEAN IS
BEGIN
  RETURN p_id IS NOT NULL;
END;

PROCEDURE processa_pedido(p_id IN NUMBER) IS
BEGIN
  IF NOT valida_pedido(p_id) THEN
    RAISE_APPLICATION_ERROR(-20001, 'ID inválido');
  END IF;
  -- lógica mais limpa aqui
END;

Erro 2: Não tratar exceções de forma adequada

Muita gente usa WHEN OTHERS THEN NULL sem pensar nas consequências.

Problema: Isso engole erros críticos e torna o debug impossível.

Solução: Sempre registre o erro ou, ao menos, retorne um código de erro claro.

-- Evite:
EXCEPTION
  WHEN OTHERS THEN
    NULL;

-- Melhor:
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE('Erro: ' || SQLERRM);
    RAISE;

Erro 3: Não padronizar nomes e estrutura

Procedures com nomes confusos, parâmetros inconsistentes ou organização despadronizada viram um pesadelo a longo prazo.

Solução: Defina um padrão (mesmo que simples). Exemplo:

  • proc_nomeDaFuncionalidade_acao (ex: proc_cliente_atualiza)

  • Sempre declare parâmetros com modo (IN, OUT) e tipo explícito

  • Comente blocos maiores


Conclusão

Escrever PL/SQL limpo é uma habilidade que se desenvolve com prática e atenção aos detalhes. Evitar esses três erros já melhora bastante a qualidade das suas procedures. Se você curte esse tipo de conteúdo mais prático, me segue aqui no Hashnode — vou postar mais dicas de PL/SQL, APIs e testes em breve!


Ficou com dúvida ou tem outro erro comum pra compartilhar? Comenta aqui ou me chama no LinkedIn!

More from this blog

Dev Prático: Carreira e Código

15 posts

Vivências, aprendizados e perrengues da vida dev.