Portuguese, Brazilian subtitles

← 06x-03 Exceptional Control Flow

06x-03 Controle de Fluxo de Exceções

Get Embed Code
3 Languages

Showing Revision 1 created 02/17/2013 by Lucilia Figueiredo.

  1. Em nosso interpretador JavaScript, usamos exceções para implementar comandos return.
  2. Isso é ruim? Deveríamos usar Python se temos que fazer isso?
  3. Bem, existe muito tratamento de exceção, no nível de linguagem, no mundo real.
  4. Eu não acho que isso seja uma razão para evitar Python ou para argumentar que uma linguagem é mais perigosa que outra.
  5. Tratamento de exceção no nível de linguagem é super popular.
  6. De fato, isso vem desde Goodenough, que em 1975 introduziu o modelo de sunstituição --
  7. esse é uim sobrenome super interessante, eu gostaria de ter um assim.
  8. E desde então, um grande número de linguagens possibilita tratar erros em programas,
  9. e questões relacionadas a ambientes, e ambos caem na categoria de
  10. exceções, no nível de linguagem. E isso realmente é muito útil, poque a abordagem anterior
  11. envolvia atribuir e verificar valores de flags globais, e programadores não são muito bons
  12. em se lembrar de fazer isso de maneira coerente e correta.
  13. Mesmo com tratamento de exceções no nível de linguagem, programadores ainda comentem muitos erros.
  14. Minha explicação pessoal é que isso é devido ao fato de que o controle de fluxo
  15. para tratamento de exceção não é visível.
  16. Quando você olha para um código Python, você pode dizer que o controle do fluxo pula para a próxima linha,
  17. se esta linha está identada em relação ao comando corrente.
  18. Mas exceções representam um certo tipo de desvio não local, para algum outro lugar,
  19. e a identação do código, ou a estrutura do código, não deixa isso claro.
  20. E se você não percebe que o código pode desviar de uma linha para outra,
  21. você pode esquecer-se de restabelecer algum invariante, ou de fechar um arquivo importante,
  22. ou de finalizar uma estrutura no final.
  23. De fato, há alguns anos atrás, quendo que estava fazendo minha dissertação nessa área --
  24. oh, trágicamente entediante -- notei que programadores de código aberto tendem a
  25. cometer da ordem de 800 erros por 4 milhões de linhas de código, relacionados apenas a tratamento de exceções.
  26. De fato, tratamento de exceção é tão proeminente que, se você olhar para um programa típico,
  27. algo entre 1% a 5% do texto desse programa consiste de blocos catch e finally.
  28. Isso pode parecer pouco, mas, tipicamente, um bloco catch ou finally, se não for simplesmente vazio,
  29. irá chamar alguma outra rotina de tratamento de erro, e grande parte do software, algo entre 3% e 46% do programa,
  30. é transitivamente atingível por meio chamadas de métodos ou o que seja,
  31. a partir desses locos catch e finally.
  32. Se você quizer em escrever grandes trechos de software robusto, que serão disponibilizados no mundo real,
  33. você irá gastar um bocado de tempo com tratamento de erros.
  34. Tratamento de exceção no nível de linguagem é, pelo menos,
  35. muito melhor do que a outra alternativa para isso.
  36. Isso seria uma razão para evitar Python?
  37. Vimos em aila que podemos usar algo como tratamento de exceção para lidar com
  38. a interpretação de comandos return de JavaScript, em nosso interpretador para JavaScript, em Python.
  39. Não, eu não evitaria Python por isso.
  40. De fato, mesmo linguagens similares, como Java, são potencialmente piores.
  41. Você pode não saber, mas Java ainda tem GOTOs -- verifique.
  42. Você pode colocar labels no programa e usar o comando break, com um argumento,
  43. para simular o comportamento de GOTOs -- mesmo sabendo-se que linguagens nominalmente mais seguras e
  44. mais estruturadas devam evitar esse tipo de coisa.
  45. Na prática, muitas linguages do mundo real -- seja Python ou Java -- têm seu lado negro,
  46. que possibilitam que você escreve código spaghetti.
  47. Isso não é apenas o caso de Python ou de JavaScript.
  48. Realmente, vem quase dessa questão filosófoca de que, algumas vezes, quando você detecta um erro,
  49. você não tem tempo suficiente, ou não tem contexto suficiente, para tratar esse erro.
  50. Esta é realmente a motivação para tratamento de exceção.
  51. Quando eu estou no meio de algum código de baixo nível que falha ao escrever algo no disco,
  52. ou falha ao enviar algo na rede, eu não sei se devo tentar novamente.
  53. Porque não? Porque depende do resto da semântica da aplicação.
  54. Se for algum tipo de gerência de rede, pode ser que eu deva aguardar por uns 5 segundos e tentar de novo,
  55. se for algo como voz sobre IP, como Skype, pode ser que eu não me importe,
  56. talvez eu apenas deva esperar pela chegada do próximo pacote.
  57. Eu não posso saber, a não ser que eu conheça mais sobre a aplicação.
  58. Então, exceções me possibiliram notificar um erro, e esperar que algum outro trecho de código,
  59. que possua mais informação, trate o erro. Esse é o caso geral em programação.
  60. e não uma situação particular a uma linguagem. Portanto, eu não diria que é um problema de Python, ou Java, ou JavaScript.