These people are not going to be happy with Python.
You can try to write Python as if it were Java or C, using Look-Before-You-Leap code instead of Easier-to-Ask-Forgiveness-than-Permission, returning error codes instead of raising exceptions for things that aren't "really" errors, etc. But you're going to end up with non-idiomatic, verbose, and inefficient code that's full of race conditions.
And you're still going to have exceptions all over the place anyway, you're just hiding them from yourself.
Hidden exceptions
Iteration
Even this simple code has a hidden exception: for i in range(10):
print(i)
Under the covers, it's equivalent to: it = iter(range(10))
while True:
try:
i = next(it)
except StopIteration:
break
else:
print(i)
That's how iterables work in Python. An iterable is something you can call iter on an get an iterator. An iterator is something you can call next on repeatedly and get 0 or more values and then a StopIteration.Of course you can try to avoid that by calling the two-argument form of
next, which lets you provide a default value instead of getting an exception. But under the covers, next(iterator, default) is basically implemented like this: try:
return next(iterator)
except StopIteration:
return default
So, even when you go out of your way try to LBYL, you still end up
EAFPing.Operators
This even simpler code also has hidden exception handling:print(a+b)Under the covers,
a+b looks something like this: def _checkni(ret):
if ret is NotImplemented: raise NotImplementedError
return ret
def add(a, b):
try:
if issubclass(type(b), type(a)):
try:
return _checkni(type(b).__radd__(b, a))
except (NotImplementedError, AttributeError):
return _checkni(type(a).__add__(a, b))
else:
try:
return _checkni(type(a).__add__(a, b))
except (NotImplementedError, AttributeError):
return _checkni(type(b).__radd__(b, a))
except (NotImplementedError, AttributeError):
raise TypeError("unsupported operand type(s) for +: '{}' and '{}'".format(
type(a).__name_, type(b).__name__))
else:
return ret
Attributes
Even the simple dot syntax in the above examples hides further exception handling. Or, for a simpler example, this code:print(spam.eggs)Under the covers,
spam.eggs looks something like this: spam.__getattribute__('eggs')
So far, so good. But, assuming you didn't define your
own __getattribute__ method, what does
the object.__getattribute__ that you inherit do? Something like this: def _searchbases(cls, name):
for c in cls.__mro__:
try:
return cls.__dict__[name]
except KeyError:
pass
raise KeyError
def __getattribute__(self, name):
try:
return self.__dict__[name]
except KeyError:
pass
try:
return _searchbases(type(self), name).__get__(self, type(self))
except KeyError:
pass
try:
getattr = _searchbases(type(self), '__getattr__')
except KeyError:
raise AttributeError("'{}' object has no attribute '{}'".format(
type(self).__name__, name))
return getattr(self, name)
Of course I cheated by
using cls.__mro__, cls.__dict__
and descriptor.__get__ above. Those are recursive calls
to __getattribute__. They get handled by base cases
for object and type.hasattr
Meanwhile, what if you want to make sure a method or value attribute
exists before you access it?Python has a
hasattr function for exactly that
purpose. How does that work? As the docs say, "This is implemented by
calling getattr(object, name) and seeing whether it
raises an AttributeError or not."Again, even when you try to LBYL, you're still raising and handling exceptions.
Objections
People who refuse to believe that Python isn't Java always raise the same arguments against EAFP.Exception handling is slow
No, it isn't. Except in the sense that Python itself is horribly slow, which is a sense that almost never matters (and, in the rare cases when it does, you're not going to use Python, so who cares?).First, remember that, at least if you're using CPython, every bytecode goes through the interpreter loop, every method call and attribute lookup is dynamically dispatched by name, every function call involves a heavy-duty operation of building a complex frame object and executing multiple bytecodes, and under the covers all the values are boxed up. In other words, Python isn't C++.
But let's do a quick comparison of the simplest possible function, then the same function plus a try statement:
def spam():
return 2
def eggs():
try:
return 2
except Exception:
return 0
When I time these with %timeit on my laptop, I get 88.9ns and 90.8ns. So, that's 2% overhead. On a more realistic function, the overhead is usually below measurability.In fact, even in C++, you'll see pretty much the same thing, unless you're using a compiler from the mid-90s. People who say "exceptions are slow" really don't know what they're talking about in any language.
But it's especially true in Python. Compare that 1.9ns cost to the 114ns cost of looking up spam as a global and calling it. If you're looking to optimize something here, the 128% overhead is surely a lot more important than the 2%.
What about when you actually raise an exception? That's a bit more expensive. It costs anywhere from 102ns to 477ns. So, that could almost quintuple the cost of your function! Yes, it could—but only if your function isn't actually doing anything. How many functions do you write that take less than 500ns to run, and which you run often enough that it makes a difference, where optimizing out 477ns is important but optimizing out 114ns isn't? My guess would be none.
And now, go back and look at the for loop from the first section. If you iterate over a million values, you're doing the 1.9ns wasted cost 999,999 times—buried inside a 114ns cost of calling next each time, itself buried in the cost of whatever actual work you do on each element. And then you're doing the 477ns wasted cost 1 time. Who cares?
Exceptions should only be for exceptional cases
Sure, but "exceptional" is a local term.Within a
for loop, reaching the end of the loop is
exceptional. To code using the loop, it's not. So the for loop handles
the StopIteration locally.Similarly, in code reading chunks out of a file, reaching the end of the file is exceptional. But in code that reads a whole file, reaching the end is a normal part of reading the whole file. So, you're going to handle the
EOFError at a low level, while the higher-level code
will just receive an iterator or list of lines or chunks or whatever
it needs.Raise exceptions, and handle them at the level at which they're exceptional—which is also generally going to be the level where you know how to handle them.
Sometimes that's the lowest possible level, in which case there isn't be much difference between using exceptions and returning
(value, True) or (None, False). But often
it's many levels up, in which case using exceptions guarantees that
you can't forget to check and percolate the error upward to the point
where you're prepared to deal with it. That, in a nutshell, is why
exceptions exist.Exceptions only work if you use them everywhere
That's true. And it's a serious problem in C++ (and even more in ObjC). But it's not a problem in Python—unless you go out of your way to create a problem by fighting against Python. Python uses exceptions everywhere. So does all the idiomatic Python code you're going to be interfacing with. So exceptions work.C++ wasn't designed around exceptions in the first place. This means:
- C++ has a mishmash of APIs (many inherited from C), some raising exceptions, others returning error values.
- C++ doesn't make it easy to wrap up error returns in exceptions. For example, your compiler almost certainly doesn't come with a helper function that wraps up a libc or POSIX function by checking for nonzero return and constructing an exception out of the errno and the name of the function—and, even if it did, that function would be painful to use everywhere.
- C++ accesses functions from C libraries just like C, meaning none of them raise exceptions. And similarly for accessing Java functions via JNI, or ObjC functions via ObjC++, or even Python functions via the Python C API. Compare that to Python bindings written with ctypes, cffi, Cython, SIP, SWIG, manually-built extension modules, Jython, PyObjC, etc.
- C++ makes it very easy to design classes that end up in an inconsistent state (or at least leak memory) when an exception is thrown; you have to manually design an RAII class for everything that needs cleanup, manage garbage yourself, etc. to get exception safety.
By comparison, ou can write exception-safe code in Python just by not doing anything stupid.
Exceptions can't be used in an expression
This one is actually true. It might be nice to be able to write:process(d[key] except KeyError: None)Of course that particular example, you can already do with
d.get(key), but not every function has
exception-raising and default-returning alternatives, and those that
do don't all do it the same way (e.g., str.find
vs. str.index), and really, doesn't expecting everyone to
write two versions of each function seem like a pretty big DRY
violation?This argument is often a bit oversold—it's rarely that important to cram something non-trivial into the middle of an expression (and you can always just wrap it in a function when it is), so it's usually only a handful of special cases where this comes up, all of which have had alternatives for decades by now.
Still, in a brand-new language an except expression seems like a better choice than
d[k] vs. d.get(k) and so
on. And it might even be worth adding today
(as PEP 463
proposes).But that's not a reason to avoid exceptions in your code.
What about Maybe types, callback/errback, Null-chaining, Promise.fail, etc.?
What about them? Just like exceptions, these techniques work if used
ubiquitously, but not if used sporadically. In Python, you can't use
them ubiquitously unless you wrap up every single builtin, stdlib, or
third-party idiomatic exception-raising function in
a Maybe-returning function.(I'm ignoring that fact that most of these don't provide any information about the failure beyond that there was a failure, because it's simple to extend most of them so they do. For example, instead of a
Maybe a that's Just a
or Nothing, useone that's Just a
or Error msg, with the same monad rules, and you're
done.)So, if you're using Haskell, use
Maybe types; if you're
using Node.js, use promises; if you're using Python, use
exceptions. Which just takes us back to the original point: if you
don't want to use exceptions, don't use Python. Race conditions
I mentioned at the top that, among other problems, trying to use LBYL everywhere is going to lead to code that's full of race conditions. Many people don't seem to understand this concept.External resources
Are these two pieces of code functionally equivalent? with tempfile.NamedTemporaryFile(dir=os.path.dirname(path), delete=False) as f:
f.write(stuff)
if not os.path.isdir(path):
os.replace(f.name, path)
return True
else:
return False
with tempfile.NamedTemporaryFile(dir=os.path.dirname(path), delete=False) as f:
f.write(stuff)
try:
os.replace(f.name, path)
return True
except IsADirectoryError:
return False
What if the user renamed a directory to the old path between
your isfile check and your replace? You're
going to get an IsADirectoryError—one that you almost
certainly aren't going to handle properly, because you thought you
designed your code to make that impossible. (In fact, if you wrote
that code, you probably didn't think to handle any of the other
possible errors…)But you can make this far worse than just an unexpected error. For example, what if you were overwriting a file rather than atomically replacing it, and you used os.access to check that he's actually allowed to replace the file? Then he can replace the file with a symlink between the check and the open, and get you to overwrite any file he's allowed to symlink, even if he didn't have write access. This may sound like a ridiculously implausible edge case, but it's a real problem that's been used to exploit real servers many times. See time-to-check-time-of-use at Wikipedia or at CWE.
Plus, the first one is much less efficient. When the path is a file—which is, generally, the most common and most important case—you're making two Python function calls instead of one, two syscalls instead of one, two filesystem accesses (which could be going out over the network) instead of one. When the path is a directory—which is rare—they'll both take about the same amount of time.
Concurrency
Even without external resources like files, you can have the same problems if you have any internal concurrency in your code—e.g., because you're usingthreading
or multiprocessing.Are these the same?
if q.empty():
return None
else:
return q.get()
try:
return q.get(block=False)
except Empty:
return None
Again, the two are different, and the first one is the one that's wrong.In the first one, if another thread gets the last element off the queue between your
empty check and your get
call, your code will end up blocking (possibly causing a deadlock, or
just hanging forever because that was the last-ever element).In the second one, there is no "between"; you will either get an element immediately, or return
None immediately.Conclusion
try:
use_exceptions()
except UserError:
sys.exit("Don't use Python")
View comments