Danny ChaiA boring followup to the exceptions thing.
Evan’s argument for exceptions is largely while I’m against them – he feels the code should be optimistic and represent what happens 99% of the time. That’s the problem with exceptions in the Python code I’ve seen. One, there is no compiler enforcement of exception handling. I can’t say for sure why, possibly because Python is interactive. But even if it weren’t, it would quickly be absurd, because most any function call can raise many kinds of exceptions.
Which gets to another point. Programs that have exceptions rarely reserve them for the truly exceptional – they almost always become some sort of error messaging mechanism. At its worst, they’re not even errors – I’ve seen code where the different exceptions raised were meant to represent different types of input; not errors at all. That’s bad code, but represents the natural inclination with exceptions – to become some sort of messaging mechanism beyond the truly exceptional.
The code I work with that most frustrates me involves user-generated content where many things can (and do) go wrong. My frustration is that a large percentage of the time, it doesn’t follow the expected code path, and figuring out which exception was raised where and where the flow of execution goes between a large number of modules is a nightmare. The exceptions basically become gotos between different files. Maintainability hell.
This can be mitigated by good coding style, but my impression is that using exceptions lends itself to bad habits, and those habits lead to code that’s far more difficult to maintain than code without exceptions. At least in my experience, which again, might be skewed by the particular Python code I’m dealing with. But seriously, figuring out what kinds of exceptions every function can raise, and where they end up when raised, is anti-fun.
No one cares.