OpenStack has an awful lot of developers writing Python code and many of us wouldn’t consider ourselves true “pythonistas”. This means we wind up having a bunch of interesting discussions about e.g. EABL vs LBYL.
A particular bugbear of mine is exception handling. I’m convinced that very, very few developers think hard about their error handling strategy and that the problem is even more serious with exception based languages.
So, I really like getting into error handling discussions. This morning, we have a great one – how to do exception chaining in Python, and whether that’s even something you want to do.
I am more familiar with Java’s exception handling, which I found to be quite predictable in it’s behaviour. This, I guess, is the point of exception handling in the first place, predictable behaviour which would allow for predicable recovery. I work in industrial environments in automation, and predictability and deterministic behaviour is the norm. Even here some developers still slip in the area of fault recovery/exception handling. Having built many machines/cells/lines over the years, I can honestly say that it is much easier to operate something when you know the details of how it works, however try getting someone who doesn’t know the “nuts and bolts” to run your little toy and that will reveal the flaws in error/exception handling and recovery. The same applies for software for PC’s, I may write programs to do all sorts of wonderful things for me, however if I haven’t written them with exception/error handling/recovery from the beginning they would likely be unusable for most other users. As for Python, I have some limited experiences with it, and never really investigated it’s exception handling method. I guess that eliminates me from being a “Pythonista”, I am however a Ducatista!