25 Abril, 2013 0 Comentários AUTOR: elemarjr CATEGORIAS: Sem categoria Etiquetas:

Usando Exceptions para demarcar limites

Tempo de leitura: Menos de um minuto

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?

0 Comentários

  1. Java#?

    Responder
  2. 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"" ?

    Responder
    • elemarjr 3 anos ago says:

      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.

      Responder
  3. Alexandre Chohfi 3 anos ago says:

    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?

    Responder
    • elemarjr 3 anos ago says:

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

      Responder
      • Alexandre Chohfi 3 anos ago says:

        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!

        Responder
        • elemarjr 3 anos ago says:

          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.

          Responder
          • Alexandre Chohfi 3 anos ago says:

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

  4. Alexandre Santos Costa 3 anos ago says:

    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!

    Responder