Nesta palestra mostrei os problemas das exceções e do gerenciamento de erros e validações em aplicação de modo geral. Introduzindo um conceito de railway simples em C#, criando uma espécie de promise para o .NET.

1. Uma abordagem funcional
para gerenciamento de erros
GABRIEL SCHADE CARDOSO

2. Quem é esse tal de Gabriel?

3.  Bacharel em ciência da computação
 Mestre em computação aplicada
 Microsoft Innovative Educator (MIE)
 Microsoft Specialist (MS)
 C#
 Javascript
 ASP .NET MVC
3
GUI
Sobre mim

4.  Microsoft Certified Solutions Assiciate (MCSA)
 Web Applications
 Autor dos livros da editora casa do código sobre
os assuntos:
 Kinect
 Windows Phone
 Programação Funcional
4
GUI
Sobre mim

5.  Desenvolvedor Senior
 Professor
 Revisor
5
GUI
Sobre mim

6. Vamos começar com
uma simples
funcionalidade

7. Mas antes...

8. Contexto

9. Contexto
 A aplicação que iremos emular a funcionalidade é:
 Escrita em C#;
 Uma aplicação Web;
 Serão Ignoradas alguns conceitos para focar no
problema principal.

10. Começando a
implementação

11. Atualizar um usuário
 Eu como usuário desejo ser capaz de atualizar meu
nome e e-mail.
 Simples de resolver!
 Primeiro vamos à classe User

12. Atualizar um usuário

13. entendendo a
implementação

14. Atualizar um usuário
1. Criar uma action para receber os dados do navegador;
2. Validar as informações recebidas;
3. Atualizar os dados do usuário;
4. Retornar uma resposta para o navegador.

15. Atualizar um usuário

16. Vamos refletir um
pouco

17. Atualizar um usuário

18. Atualizar um usuário

19. Atualizar um usuário

20. Atualizar um usuário

21. Atualizar um usuário

22. Atualizar um usuário
1. A função de validação como void?
2. A função de atualização como void?
3. O valor de retorno é um texto escrito “OK”?
4. Mas... E se algo der errado?

23. Vamos ver como as
funções estão

24. Atualizar um usuário

25. Atualizar um usuário

26. Atualizar um usuário
 Nos dois casos estamos lançando exceções quando
as coisas não ocorrem bem.
 Como a resposta chegará ao navegador desta forma?

27. Atualizar um usuário

28. Atualizar um usuário

29. Atualizar um usuário
 Como as exceções não estão sendo tratadas, acabamos
sempre retornando um erro 500.
 Este HTTP code não deve ser utilizado para isso,
precisamos retornar um 400 (bad request).
 Onde colocar esse tratamento?

31. Atualizar um usuário
 Onde nos perdemos?
 Abusar de exceções
 Interromper o fluxo do
programa

32. Atualizar um usuário
 As exceções não devem ser utilizadas para erros de
validação.
 Erros de validação fazem parte de uma regra não de
uma exceção.
 Coisas como: O HD do servidor explodiu devem ser
exceções, um usuário digitar um e-mail com formato
inválido é algo normal e esperado.

33. Vamos voltar e
reescrever as coisas

34. Mas antes, um pouco
de contexto

35. Contextualização
 Responsabilidade única
 Composição
 Containers

36. Responsabilidade única

37. Responsabilidade única
 O Princípio da responsabilidade única (o S do famoso
SOLID) indica que, uma classe deve ter apenas UMA
responsabilidade.
 Este princípio pode (e deve) ser extrapolado para
métodos.
 Cada método deve fazer uma única coisa.

38. Responsabilidade única
 No exemplo anterior o método Validate validava três
coisas diferentes: nome em branco, e-mail em branco
e formato do e-mail.
 Seria uma boa ideia separá-los em três métodos
diferentes, cada um validando apenas uma coisa.

39. Responsabilidade única
 Mas todas as vezes que fosse preciso validar um
usuário, teríamos que chamar as três funções?
 Mais ou menos.
 Para isso utilizamos funções compostas.

40. Composição

42. Composição
 As funções compostas é um conteúdo que
aprendemos na escola na disciplina de matemática.
 As funções compostas também podem ser chamadas
de função de função.
 É um tipo específico de função que representa a
combinação de duas ou mais funções.

43. Composição
 Tendo uma função f (A  B) e uma função g (B  C)
podemos representar uma composição de f e g como:
f >> g( A  C)
 Também podemos representar como:
g( f (A) )

44. Composição
 Então, se a função g for chamada com a saída da
função f e ...

45. Composição
 Então, se a função g for chamada com a saída da
função f e ...

46. Calma...

47. Composição
 Basicamente o que a composição faz é conectar a
saída de uma função como parâmetro da função
seguinte.
 Vamos mostrar um código simples para ilustrar isso...

48. Composição

49. Composição

50. Composição

51. Composição

52. Composição

53. Composição

54. Composição
 Como uma função retorna apenas um valor, as
funções que realizam uma composição precisam
receber apenas um parâmetro.
 O que parece bem ruim...
 Mas não é, porque TODA função pode conter apenas
um parâmetro. (Mas isso fica para outro dia)

55. Composição
 Basicamente as funções que criamos devem servir
como peças de lego
 Para resolvermos problemas maiores criamos um
bloco com estas peças (funções compostas).

56. Composição
 Uma combinação de: Composição + Containers pode
ser extremamente poderosa para criação de um código
expressivo.
 Mas... O que é um container?

57. Containers

58. Containers

59. Containers
 Um container pode ser visto como um envelope ou
uma caixa que circunda um dado, incluindo-o em
algum contexto específico.
 Lidamos com este tipo de valor o tempo todo:
1. List;
2. Array;
3. Task;
4. Nullable.

60. Containers
 Imagine o seguinte cenário: você possui um dado do
tipo inteiro e precisa somá-lo com o valor 3.

61. Containers
 E se este número estiver em um array?.

62. Containers
 Não podemos realizar a soma com o mesmo valor,
isso por conta do contexto que o cerca.
 Por isso, comumente temos uma função para
remover o valor de seu contexto.

63. Containers
 No caso do array o indexador remove o valor do
contexto.

64. Containers
 Podemos nos aproveitar deste conceito para criar
novos objetos e classes que armazenam valores sob
um determinado contexto.

65. Uma ideia para
nosso problema

66. Primeira Implementação

67. Segunda implementação

68. Objetivo

69. Objetivo

70. Como produzir dois
possíveis resultados em
cada etapa?

71. Criando um Novo tipo

72. Criando um novo tipo
 Este tipo precisa representar um resultado;
 Este resultado pode ser um sucesso ou uma falha;

73. Criando um novo tipo
 Os tipos referentes aos valores de sucesso e falha
não pode ser fixos, portanto generics;

74. Criando um novo tipo
 Notem que as propriedades de nossa classe só
possuem um método get, ou seja, todas elas são
readonly;
 Precisamos de construtores!

75. Criando um novo tipo
 Em um construtor
temos apenas os
dados de sucesso, no
outro os de falha.

76. Criando um novo tipo
 Com nosso novo container já é possível retornar um
resultado!
 Vamos começar adaptando a função Update!

77. Refatorando

78. Refatorando

79. Refatorando
1. Return em dois locais diferentes;
 Apesar da maior parte das vezes isso ser uma prática
ruim, como temos dois tipos de retorno diferentes, é
natural termos dois retornos.

80. Refatorando
1. Return em dois locais diferentes;
2. Ainda usamos try-catch;

81. Refatorando
1. Return em dois locais diferentes;
2. Ainda usamos try-catch;
 Precisamos especificar os casos, onde há problema
de conexão com o banco e onde o usuário que
estamos atualizando não existe no sistema

82. Refatorando
2. Ainda usamos try-catch;
 Onde o usuário não estiver cadastrado no banco:
 Precisamos validar e retornar um erro quando precisar;

83. Refatorando
2. Ainda usamos try-catch;
 Onde ocorrer erro de conexão com o banco:
 Não precisamos fazer nada
¯ _ (ツ) _ / ¯

84. Refatorando
1. Return em dois locais diferentes;
2. Ainda usamos try-catch;
3. A criação do Result é trabalhosa;

85. Refatorando
 Vamos apelar para a linguagem, podemos
sobrecarregar o operador de cast (conversão entre
tipos);
 Dessa forma passamos a responsabilidade de
converter o objeto para a linguagem.

86. Refatorando
 Voltando ao nosso tipo Result...
 Uma sobrecarga para sucesso e outra para falhas:

87. Refatorando

88. Refatorando

89. Refatorando

90. Refatorando

91. Refatorando

92. Vencemos o update!

93. Agora vamos para o
Validate!

94. Refatorando
1. Acumula os erros em
uma lista;
2. Lança exceção quando
houver erros.
3. Definido como void

95. Refatorando
 Vamos utilizar a própria linguagem para gerar a lista;

96. Refatorando
 Utilizar a própria linguagem para gerar a lista;
 Vamos retornar as mensagens de erro, sem gerar
exceções.

97. Voltando ao controller!

99. Refatorando
1. Remover os try-catches;
2. Retornar os dados ou as mensagens de erro.

106. Refatorando
 Parece uma composição!
 Só que ruim.
 A solução ainda está bem estranha, com vários If’s e
comparações.
 E se encapsulássemos isso de uma forma que a
composição faça mais sentido?

107. Uma última passada no
tipo!

108. Voltando ao tipo!
 Agora é onde a magia acontece!
 Vamos implementar em nossa classe 2 novos
métodos: Then e Catch.
 Estes serão os métodos que utilizaremos para
composição!

109. Voltando ao tipo!
 Os dois métodos possuem apenas uma linha, mas
são um tanto quanto complexo, mas calma, eu explico.
 Primeiro vamos ao método Then

110. Voltando ao tipo!
 Este método precisa retornar um novo objeto Result,
podendo inclusive ter outro tipo de sucesso.
 Também precisaremos receber um parâmetro!

111. Voltando ao tipo!
 E o parâmetro que vamos receber também é um
método. Ele será o segundo método da função
composta!
 O C# utiliza delegates para descrever métodos, entre
eles temos o delegate Func<Tin, Tout> que descreve
uma função com 1 parâmetro e 1 retorno.

112. Voltado ao tipo!
 A função precisa receber o retorno da anterior e deve
retornar um sucesso igual ao da assinatura do método
Then!

113. Voltando ao tipo!
 A função precisa receber o retorno da anterior e deve
retornar um sucesso igual ao da assinatura do método
Then!

114. Voltando ao tipo!
 A função precisa receber o retorno da anterior e deve
retornar um sucesso igual ao da assinatura do método
Then!

115. Voltando ao tipo!
 A lógica do método Then é muito simples, basta
verificar se o Result atual foi um sucesso.
 caso sim: execute o próximo método.
 caso não, retorne sua falha

116. Voltando ao tipo!
 Os dois métodos possuem apenas uma linha, mas
são um tanto quanto complexo, mas calma, eu explico.
 Primeiro vamos ao método Then
 Agora o método Catch

117. Voltando ao tipo!
 Este método é semelhante ao Then, mas agora
vamos retornar apenas o valor de sucesso, sem ser
um novo resultado;
 O catch deve ser a última coisa a ocorrer;

118. Voltando ao tipo!
 Neste caso faremos a verificação contrário do método
Then, chamando a função de falha, apenas se há uma
falha no Result;

119. Voltando ao tipo!
 Um último adendo...
 O tipo Result é criado diversas vezes em uma
operação, por conta disso é fortemente recomendado
utilizarmos uma struct ao invés de uma classe.
 Basta substituir a palavra reservada:

120. Vamos ver a magia
acontecer no controller

122. Reta final!
 Não precisamos mais expor os ifs aqui, podemos
utilizar o Then;

123. Reta final!
 Mas se tentarmos utilizar no método Update;

124. Reta final!
 Mas se tentarmos utilizar no método Update;

125. Reta final!
 Isso ocorre porque o método Update espera dois
parâmetros (contexto e usuário) e o parâmetro da
função Then é um método com apenas um parâmetro;

126. Reta final!
 Mas é só criarmos um método anônimo através de
expressão lambda!

127. Reta final!
 Mas é só criarmos um método anônimo através de
expressão lambda!

128. Reta final!
 Talvez você já tenha percebido, mas podemos
concatenar os métodos Then sem precisarmos
armazenar os resultados intermediários!

129. Reta final!

130. A cereja do bolo

131. Resultado final
 Como o método Then pode produzir novos
resultados, podemos incluir um Then para converter o
resultado em uma IHttpActionResult para retornarmos
o OK...

132. Resultado final
 E no fim de tudo criamos um método Catch para
retornar um bad request se alguma falha ocorrer no
caminho!
 E com isso teremos um método completamente
composto, feito de uma instrução de return...

133. Resultado final
 Com isso saímos...

134. Daqui

135. E chegamos aqui

136. E chegamos aqui

137. Resultado final
 Com isso finalizamos toda a implementação do
gerenciamento de erros através de uma abordagem
funcional.
 Evitei utilizar termos comuns na programação
funcional justamente para mostrar que não é o bicho
de sete cabeças que imaginam

138. Perguntas?

139. Me encontre em
/gabrielschade
/gabrielschade
/gabrielschade
/gabrielschade
https://gabrielschade.github.io