Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Exceptions: Why, When, How and Where!

635 vues

Publié le

A presentation that shows from where Exception came, how to use them, when to use them, why to use them with a implementation example in Ruby

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Exceptions: Why, When, How and Where!

  1. 1. Exceptions Hernán A. Wilkinson @hernanwilkinson – www.10pines.com agile software development & services
  2. 2. Where do they came from?
  3. 3. What is the problem?
  4. 4. Repeated code!
  5. 5. Code != Text
  6. 6. Code != Text Repeated Code = Repeated patterns of collaboration
  7. 7. What does it mean to have “repeated code”?
  8. 8. Repeated Code Means ● Lack of abstraction ● In OO terms: Lack of an Object
  9. 9. How do we remove it?
  10. 10. Removing Repeated Code 1. Contextual-Move repeated code to some “place” 2. Parameterize what changes (including types) 3. NAME IT!  The most important step 4. Use it :-)
  11. 11. Contextual Move
  12. 12. What changes?
  13. 13. How do we parameterize it?
  14. 14. Polymorphism
  15. 15. How do we parameterize it?
  16. 16. Closure
  17. 17. Name it! – The most important step
  18. 18. And if you are a good ruby programmer
  19. 19. Error Codes
  20. 20. What is the problem?
  21. 21. And now, what is the problem?
  22. 22. Repeated Code!
  23. 23. Better, but…
  24. 24. Repeated code!
  25. 25. Cool! No repeated code! No way to forget to handle the error!
  26. 26. Much nicer!
  27. 27. But… I don’t want to panic! I want to stop execution and return the error!
  28. 28. Will stop execution?
  29. 29. Full Closure to the rescue!!
  30. 30. Ruby What will be printed?
  31. 31. 15 10
  32. 32. Only if we could do this in Go…
  33. 33. What are Exceptions?
  34. 34. Exceptions Conceptually An indication that a ”Contract” has been violated Pragmatically Abstraction that removes “repeated code” from the “error code technique”
  35. 35. Contract & Contract Violation
  36. 36. Implicit Contract Type Explicit
  37. 37. Contract Definition
  38. 38. Contract Definition Pre-conditions
  39. 39. Contract Definition Pre-conditions Post-conditions
  40. 40. Contract Definition Pre-conditions Post-conditions Invariant
  41. 41. Contract Definition Extract method!
  42. 42. Contract Definition
  43. 43. Contract Definition Extract method!
  44. 44. Contract Definition
  45. 45. Contract Definition Extract method!
  46. 46. Contract Definition
  47. 47. Contract Definition Generalization
  48. 48. Contract Definition
  49. 49. Contract Definition Too expensive!
  50. 50. Contract Definition We convert them to tests!
  51. 51. Contract Definition What do we do with it?
  52. 52. Contract Definition – Pre-Conditions The sender has to satisfy it, the receiver assumes the sender is “nice and cool” C school (Bell Labs/Berkeley)
  53. 53. Contract Definition – Pre-Conditions The receiver checks the sender complies with it. The receiver does not trust the sender Lisp school (MIT)
  54. 54. Contract Definition Lisp school (MIT) wins! – Always check pre-conditions
  55. 55. When to raise an Exception? When a contract is violated In the business code: When a pre-condition is not meet In the tests: When a post-condition or invariant is not meet
  56. 56. Who raises exceptions? object 1 object 2 object 3 object 4 object 5 object 6 object 7 m5 m2 m3 m4 m6 m1
  57. 57. Who raises exceptions? object 1 object 2 object 3 object 4 object 5 object 6 object 7 m5 m2 m3 m4 m6 m1 The ones at the bottom because they are the ones that do the real stuff
  58. 58. Who handles exceptions? object 1 object 2 object 3 object 4 object 5 object 6 object 7 m5 m2 m3 m4 m6 m1
  59. 59. Who handles exceptions? object 1 object 2 object 3 object 4 object 5 object 6 object 7 m5 m2 m3 m4 m6 m1 The ones at the top because they have all the context of what is going on
  60. 60. How to Handle Exceptions • Let’s see some examples
  61. 61. How to Handle Exceptions • Unexpected Exceptions  nothing to do! • Expected Exceptions  the ones that can be handled • If they are expected, are they exceptions? • Would not be better to have parameters to pass handler for the expected “exceptions”?
  62. 62. How to Handle Exceptions NEVER!!!
  63. 63. Which Exception should be raise? • One per “error type”? • CanNotWithdrawException, CanNotPrintException, CanNotOpenFileException, etc. • Always the same, ex. Exception? • It depends?
  64. 64. Which Exception should be raise? • If the exception will not be handled, use Exception • If the exception will be handled, use a specific one • If you are writing a framework/library  you don’t know how they will be handled by users  over design • If you ”own” the code (ex. Teespring)  create new ones as need it to handle them
  65. 65. Implementation!
  66. 66. Implementation ● A Fully Object-Oriented Exception Handling System (Christophe Dony) ● Implementing Exceptions with Ruby: https://www.youtube.com/playlist?list=PLMkq_h36PcLAE5CPRGG5xd62KVJABPQdd
  67. 67. Thanks! Hernán A. Wilkinson @hernanwilkinson – www.10pines.com agile software development & services

×