Just some more oil for the fire. Having worked primarily in Python for over 10 years (and generally been a huge enthusiast during that time), I'm pretty comfort

Just some more oil for the fire. Having worked primarily in Python for over 10 years (and generally been a huge enthusiast during that time), I'm pretty comfortable at this stage with the notion that exception handling languages contribute significantly in only one respect - they allow newbies to write code without ever properly understanding how errors should be managed without violating layering, where retries should be inserted, and so on. The culture of writing code, and that code being fine once a unit test is passing seems to propagate the myth that it's fine for any code to throw any exception at any time – it doesn't matter as long as those errors expected to occur from testing are the only conditions that ever occur. As for the rest, well. Kaboom! Starting off from C, it doesn't take you more than your first 100 lines before you discover pain due to missing a return value. In my experience, eventually 60% of your time is spent wondering how this particular return value propagates throughout the rest of the code you've written, and libraries in use. The end result is my C code tends to be much more robust in the face of braindamage (say, network errors, IO errors) than my Python, simply as a result of a cultural mindset that basically encourages ignorance of error conditions. You can also trace one of the biggest pains from Python 2 back to this culture: deferred error handling is at the very core of the Unicode/strings mess, probably the single most motivating factor for moving to Python 3. [Extremely tired, aware this is poorly written and sways between points, but hope it makes some sense]