Elemar DEV

Negócios, tecnologia e desenvolvimento

Usando Exceptions para demarcar limites

Olá pessoal. Tudo certo?

Depois de um tempinho sem postar nada com códigos, resolvo fazer uma pequena provocação.

Atente para o código que segue:

public static ASTEmitter Parse(
  string expression,
  IHelperResolver resolver,
  bool resolving = false,
  bool simplifying = false
  )
  {
    try
    {
      var emitter = new ASTEmitter(resolver, expression, simplifying, resolving);
      using (var parser = new ExpressionParser(
        (resolving
        ? new ExpressionScanner().String(expression)
        : new ExpressionScanner().Scan(expression)
        ), emitter)
      {
         parser.Parse();
      }
      return emitter;
    }
    catch (Exception inner)
    {
      throw new FailedToCompileOrResolveException(expression, inner);
    }
}

O que temos aqui? Simples! Estou bloqueando e “envelopando” exceptions disparadas nos métodos privados ou internos, das classes internas, que forem invocadas a partir daqui. A grande pergunta é: Por quê?

Penso, honestamente, que métodos privados (ou internos) não devem figurar no callstack. Ou melhor, se estiverem, devem estar “envolvidos” por uma exception que identifique claramente a operação que estava sendo executada quando o “problema” aconteceu. Dessa forma, temos algo com um pouco mais de significado para o “programador cliente”. Além disso, demarcamos claramente os limites de nossa API.

O que você acha disso?

10 comentários em “Usando Exceptions para demarcar limites

  1. Quando desenvolvo APIs, procuro nos métodos de uso público, tratar erros devolvendo mensagens que façam sentido para os “consumidores”. Acho isto bem melhor, do que devolver uma Exception “pura” do framework. Mas agora pergunto: E em WebAPI: devolvover sempre nas Actions um “new HttpResponseMessage” ou um “throw new HttpException(httpMessage, “msg”” ?

    • elemarjr
      30/04/2013

      Em uma WebAPI, a principal preocupação deve ser com o código de retorno. Não com a mensagem.

      Se sua API estiver modelada adequadamente, então, estará usando os verbos HTTP de forma consistente. Falhas de operação devem ser retornadas de forma coerente com a especificação.

  2. Alexandre Chohfi
    29/04/2013

    Acho isso necessário, mas deve ser usado com cuidado, por exemplo, envelopar uma exception já específica da sua API com outra exception mais específica, sendo que esta 1a exception vem de um método publico, faz sentido sempre?

    • elemarjr
      29/04/2013

      Por que haveria uma exception específica sendo lançada em um método privado?

      • Alexandre Chohfi
        29/04/2013

        Não, 1 método publico, internamente chama outro método publico que já tem uma exception específica, não faz sentido envelopar isso!

        • elemarjr
          29/04/2013

          Nesse caso, realmente não faria sentido. Desde que a exception faça sentido para quem está consumindo a API.

          Minha implicância está em exceptions escondidas em métodos privados.

          • Alexandre Chohfi
            29/04/2013

            Sim, faz sentido.
            Preciso fazer mais isso, não estou acostumado a fazer este tipo de tratamento.

  3. Elemar,

    Muito bom post. REalmente temos de ser o mais clarospossíveis quando informamos ao usuário de nossa API sobre um erro e envelopar as exceptions de métodos privados é uma excelente forma de fazer isto.
    AQui na empresa sofremos com dois problemas da não utilização, ou utilização incorreta , dsta prática.
    A primeira é que quando apenas subimos a exceção temos desenvolvedores preguiçosos que a ignoam e mandam um e-mail diznedo que nossa api está com um erro, mesmo que seja uma FileNotFoundException infromando que o parametro que ele passou é um arquivo que não exista.
    A outra é que em alguns momentos exceções são generalizadas e mascaradas (não é propagada como inner) escondendo um real problema nos trazendo horas de debuging para diagnosticar o que houve.
    Continue com o excelente trabalho!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado às 25/04/2013 por em Post e marcado .

Estatísticas

  • 703,042 hits
%d blogueiros gostam disto: