Exceptions: Why, When, How and Where!
Download as PPTX, PDF1 like1,052 views
The document discusses the issue of repeated code in software development, emphasizing its impact on collaboration and the importance of abstraction. It outlines strategies for removing repeated code, such as contextual movement, parameterization, and naming, while also addressing the role of exceptions and how to handle them effectively. The discussion draws on concepts from object-oriented programming, pre-conditions, and contract definitions, asserting the need for proper exception handling to ensure robust software design.
More Related Content
Similar to Exceptions: Why, When, How and Where! (20)
![[XPday.vn] Legacy code workshop (at) [XP Day Vietnam 2015]](https://cdn.slidesharecdn.com/ss_thumbnails/xpday-150421041526-conversion-gate01-thumbnail.jpg?width=560&fit=bounds)
More from Hernan Wilkinson (20)
Exceptions: Why, When, How and Where!
- 1. Exceptions Hernán A. Wilkinson @hernanwilkinson – www.10pines.com agile software development & services
- 2. Where do they came from?
- 5. What is the problem?
- 7. Code != Text
- 8. Code != Text Repeated Code = Repeated patterns of collaboration
- 9. What does it mean to have “repeated code”?
- 10. Repeated Code Means ● Lack of abstraction ● In OO terms: Lack of an Object
- 11. How do we remove it?
- 12. 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 :-)
- 13. Contextual Move
- 14. What changes?
- 16. How do we parameterize it?
- 17. Polymorphism
- 18. How do we parameterize it?
- 19. Closure
- 20. Name it! – The most important step
- 21. And if you are a good ruby programmer
- 23. Error Codes
- 24. What is the problem?
- 26. And now, what is the problem?
- 27. Repeated Code!
- 29. Better, but…
- 30. Repeated code!
- 32. Cool! No repeated code! No way to forget to handle the error!
- 33. Much nicer!
- 34. But… I don’t want to panic! I want to stop execution and return the error!
- 37. Full Closure to the rescue!!
- 38. Ruby What will be printed?
- 39. 15 10
- 40. Only if we could do this in Go…
- 42. Exceptions Conceptually An indication that a ”Contract” has been violated Pragmatically Abstraction that removes “repeated code” from the “error code technique”
- 58. Contract Definition We convert them to tests!
- 59. Contract Definition What do we do with it?
- 60. Contract Definition – Pre-Conditions The sender has to satisfy it, the receiver assumes the sender is “nice and cool” C school (Bell Labs/Berkeley)
- 61. Contract Definition – Pre-Conditions The receiver checks the sender complies with it. The receiver does not trust the sender Lisp school (MIT)
- 62. Contract Definition Lisp school (MIT) wins! – Always check pre-conditions
- 63. 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
- 64. Who raises exceptions? object 1 object 2 object 3 object 4 object 5 object 6 object 7 m5 m2 m3 m4 m6 m1
- 65. 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
- 66. Who handles exceptions? object 1 object 2 object 3 object 4 object 5 object 6 object 7 m5 m2 m3 m4 m6 m1
- 67. 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
- 68. How to Handle Exceptions • Let’s see some examples
- 69. 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”?
- 70. How to Handle Exceptions NEVER!!!
- 71. Which Exception should be raise? • One per “error type”? • CanNotWithdrawException, CanNotPrintException, CanNotOpenFileException, etc. • Always the same, ex. Exception? • It depends?
- 72. 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
- 73. Implementation!
- 74. Implementation ● A Fully Object-Oriented Exception Handling System (Christophe Dony) ● Implementing Exceptions with Ruby: https://www.youtube.com/playlist?list=PLMkq_h36PcLAE5CPRGG5xd62KVJABPQdd
- 75. Thanks! Hernán A. Wilkinson @hernanwilkinson – www.10pines.com agile software development & services