4. Do you know _MURPHY_? You should, since he’s developing your software, deploying and releasing, testing and using it. He’s also designing and operating the whole hardware your programs are running on
6. The very question is: do you _REALLY_ know everything that can go wrong?
7. You can cover your cleaner bottle with hazard symbols, and still there will be a genius who will clean his teeth with it
8. Or in topic relevant terms, look at this line of code: C = A / B
9.
10. Was it all? No, there’s more: 5. C assumed to be a string 6. C gets overwritten 7. A, B, C not thread safe 8. C = 0 through rounding 9. this is copy/paste code . . . C = A / B
11. And that’s just one LOC. Now imagine the explosion with every further LOC
14. _DEFENSIVE_PROGRAMMING_ is what they taught us to do: critical if (isnum(A) and isnum(B) and (A > B * 10) and (B > 0)) try C = A / B catch (DivisionByZero) …
15. And of course you will omit the one which will crash the whole thing
16. So what you sometimes are trying to do is: catch (WrongStellarConstellation) //move stars catch (WrongSunPosition) //move after the sun catch (Angle45DegreeToHorizon) //run for your life catch (*) //just for the case
35. _YOU_NEED_ “ Virtual” processing units much smaller than your OS’s processes / threads Their cheapness pays off when they get scheduled through zero/minimal context switching and possibility to run 100’000s of them in one single VM instance
37. _YOU_NEED_ A virtual machine to run these actors, to schedule them, to control resources
38. _YOU_NEED_ Mechanisms in your VM to protect and isolate single actors from each other and the whole VM from the actors Actors must pass messages instead of sharing resources in order to minimize dependencies
40. _YOU_NEED_ To be able to externalize actor’s state Actors get their state from some storage / another actor with every new “call” and return a modified state for further storage
41. _YOU_NEED_ An onion alike, layered model When an actor crashes, another one still “stores” its state and can pass it on to a new actor
42. _YOU_NEED_ Ideally a functional programming approach There, you can only apply state from outside and get back a modified one
43. _YOU_NEED_ Mechanisms which allow an actor to automatically get informed when an other actor crashes Also mechanisms to link actors together so they “die” together
56. Same approach works (with minimal modifications) not only on one node, but on several nodes and even distributed over a network. That allows building true fault-tolerant systems
57. Erlang was invented to program switches, control networks etc. It’s been designed for the mentioned hardware and network “ reliability”
64. _ASK_YOURSELF_ Should I handle this error? Defensive programming and “let it crash” philosophy must not exclude each other
65. _ASK_YOURSELF_ How should I handle this error? Throw an exception? Return a value? Ignore? Write a log? Terminate the program?
66. _ASK_YOURSELF_ Can I terminate / crash here? Do I have to go on? Can I go on from here at all?
67. _ASK_YOURSELF_ Can I leave some garbage after I crash? Do I have to clean up before / after I do?
68. _ASK_YOURSELF_ When I restart a worker, how can I know it doesn’t crash again, and again?..
69. _ASK_YOURSELF_ Why do I expect wrong function parameters? Don’t I trust my own non-API calls? Shouldn’t I fix this outside?
70. _ASK_YOURSELF_ When should I prefer in-place error handlers? When should I better go for a central error handler knowing about all types of possible errors?
71. _ASK_YOURSELF_ Do I have to check parameter types? Do I have to generally check the semantics of the API function parameters, implement a contract?
72. With all this in mind: Don’t program too defensively. _LET_IT_CRASH_
74. Presentation inspired by the work of Joe Armstrong, Steve Vinoski, Mazen Harake, Jonas Bonér and Kresten Krab Thorup Most images originate from istockphoto.com except few ones taken from Wikipedia and product pages