English subtitles

← Exceptional Control Flow - Programming Languages

Get Embed Code
3 Languages

Showing Revision 2 created 05/25/2016 by Udacity Robot.

  1. In our JavaScript interpreter, we used exceptions ro implement return statements.
  2. Is this bad? Should we be using Python if we have to do this?
  3. Well, there is a lot of language-level exception handling in the real world.
  4. I don't think it's a reason to avoid Python or claim that one language is more dangerous than another.
  5. Language-level exception handling is super popular.
  6. It's actually goes back to Goodenough in 1975 who introduced a replacement model.
  7. That is an amazing family name. I wish I had that name.
  8. And since then, a number of languages have allowed you to deal with programmer errors
  9. and environmental concerns--both of which are often lump under the category
  10. of exceptions at the language level, and this actually is super handy because the previous
  11. approach involves sort of setting and checking global flags and programmers are very poor
  12. at remembering to do that consistently and correctly.
  13. Even with language level exception handling, it turns out that programmers make a lot of mistakes.
  14. One of the personal hypothesis is that this is because the control flow
  15. for exception handling isn't visible.
  16. When you're looking at the code, you can tell the control is going to flow down to the next line.
  17. if there's a statement in Python it's indented over.
  18. But exceptions really represent this sort of nonlocal jump to somewhere else
  19. and the indenting of the coder, the structure of the code may not make it clear.
  20. And if you're not aware that code can jump out of one line and go to another.
  21. You may forget to reestablish some in variant or close some important file
  22. or finalize a day of the structure by the end.
  23. And in fact, even a number of years ago, when I was doing my dissertation on the subject--
  24. Oh, tragically boring--open source job of programmers tended to make
  25. on the order of 800 mistakes per 4 million lines of code related to exception handling alone.
  26. And in fact, exception handling is so prominent that if you look at an average program
  27. somewhere between 1% and 5% of the text of that program will literally be catch and finally blocks.
  28. That may actually seem low but typically a catcher or finally block, if it's not just empty
  29. will call some error handling routine and in large pieces of software, anywhere between 3 and 46%
  30. of the program is transitively reachable through methods calls or what not
  31. from catch and finally blocks.
  32. If you're interested in writing large robust pieces of software that get deployed in the real world,
  33. You will spend quite a bit of time dealing with handling errors.
  34. Language-level exception handling is at least for now
  35. much better than the alternative for that sort of thing.
  36. Is this a reason to avoid Python?
  37. We saw in class that we could use something like exception handling to deal with
  38. interpreting JavaScript return statements in our Python JavaScript interpreter?
  39. No, I wouldn't devoid Python as a result.
  40. In fact, even nominally friendlier languages like Java are potentially worse.
  41. You may not be aware of this Java actually still has GOTOs--go check it out.
  42. You can put in labels and then reuse the brake statement if you're given an argument
  43. to behave like GOTOs, so even though nominally more typed safe,
  44. more structured languages are supposed to avoid that sort of thing.
  45. In practice, a lot of real world languages be the Python or be the Java have their secret dark
  46. corners allowing you to write unstructured spaghetti code.
  47. This is nothing particularly bad about Python or particularly bad about JavaScript.
  48. It really gets back to this almost philosophical issue that sometimes when you detect an error,
  49. you don't have enough time, you don't have enough context to deal with it.
  50. That's really the motivation for exception handling.
  51. When I'm in the middle of some low level codes that fails to write something to the disc
  52. or fails to send something over the network, I don't know if should retry.
  53. Why not? Depends on the rest of the application semantics.
  54. If it's some sort of network maneuver may be I want to sleep for five seconds and try again,
  55. or if it's something like voice over IP like Skype may be I don't want to bother,
  56. may be I'll just wait for the next packet to arrive.
  57. I can't know unless I know more about the application semantics.
  58. So exceptions allow me to throw that notice of an error up and hopefully someone else
  59. who has more information will catch it--that's generic to the experience of programming.
  60. It's not particular to any one language so I wouldn't hold it against Python or Java or even JavaScript.