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

Matheus AlmeidaMatheus Almeida
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!

0
Subscribe to my newsletter

Read articles from Matheus Almeida directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Matheus Almeida
Matheus Almeida

Desenvolvedor focado em PL/SQL, Java, Angular e qualidade de código.