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

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?

6. Repeated code!

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!

36. Will stop execution?

37. Full Closure to the rescue!!

38. Ruby
What will be printed?

39. 15
10

40. Only if we could do this in Go…

41. What are Exceptions?

42. Exceptions
Conceptually
An indication that a ”Contract” has been violated
Pragmatically
Abstraction that removes “repeated code” from the “error code technique”

43. Contract &
Contract Violation

44. Implicit
Contract Type
Explicit

45. Contract Definition

46. Contract Definition
Pre-conditions

47. Contract Definition
Pre-conditions
Post-conditions

48. Contract Definition
Pre-conditions
Post-conditions
Invariant

49. Contract Definition
Extract method!

50. Contract Definition

51. Contract Definition
Extract method!

52. Contract Definition

53. Contract Definition
Extract method!

54. Contract Definition

55. Contract Definition
Generalization

56. Contract Definition

57. Contract Definition
Too expensive!

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