Dead Programs Tell no Lies

The next section of the book is called Dead Programs Tell no Lies, haha. This refers back to something we talked about earlier. We need to fail fast in order to be able to pin down problems in he code properly. That’s what they mean by dead programs tell no lies. Because if you fail fast, you are at the root of the problem.

David and Thomas say; Crash, don’t thrash! Just crash early and don’t write corrupted data into your production database for example. Have you ever experienced trying to print a single page and your printer starts spitting out page after page after page? I mean how god damn annoying is that! It happened to me this week. Printers always seem to have some issues haha. They are a breeding ground for spaghetti monster saplings.

But to get back to the book. The authors say that Java and many libraries have embraced this philosophy. When shit happens, (run-time) exceptions are thrown and if not handled, they proliferate.

Now… this is where we can have a discussion since both Uncle Bob and Prof. Ousterhout have strong opinions about this. Throwing a shit ton of run-time exceptions is not great. We will take a more detailed look at exceptions in a later section of the chapter but I do want to emphasize Prof. Ousterhout’s principle of ‘defining errors out of existence’. Sometimes you don’t need to throw exceptions for every misstep. Sometimes you are perfectly capable of recovering and salvaging the situation. It’s certainly not always the case, but if you can, you should! But we will discuss this in a later section!



01010010 01110101 01100010 01100101 01101110

Hey, sorry to bother you but you can subscribe to my blog here.

Never miss a blog post!

You have Successfully Subscribed!