On Sun, 25 Jul 2010 14:47:11 +0000, Steven D'Aprano wrote: >>> But in the >>> meanwhile, once you get an error, you know what it is. You can >>> intentionally feed code bad data and see what you get. And then maybe >>> add a test to make sure your code traps such errors. >> >> That doesn't really help with exceptions which are triggered by external >> factors rather than explicit inputs. > > Huh? What do you mean by "external factors"?
I mean this: > If you mean external factors like "the network goes down" or "the disk is > full", > you can still test for those with appropriate test doubles (think > "stunt doubles", only for testing) such as stubs or mocks. It's a little > bit more work (sometimes a lot more work), but it can be done. I'd say "a lot" is more often the case. >> Also, if you're writing libraries (rather than self-contained programs), >> you have no control over the arguments. > > You can't control what the caller passes to you, but once you have it, > you have total control over it. Total control insofar as you can wrap all method calls in semi-bare excepts (i.e. catch any Exception but not Interrupt). >> Coupled with the fact that duck >> typing is quite widely advocated in Python circles, you're stuck with >> the possibility that any method call on any argument can raise any >> exception. This is even true for calls to standard library functions or >> methods of standard classes if you're passing caller-supplied objects as >> arguments. > > That's a gross exaggeration. It's true that some methods could in theory > raise any exception, but in practice most exceptions are vanishingly > rare. Now *that* is a gross exaggeration. Exceptions are by their nature exceptional, in some sense of the word. But a substantial part of Python development is playing whac-a-mole with exceptions. Write code, run code, get traceback, either fix the cause (LBYL) or handle the exception (EAFP), wash, rinse, repeat. > And it isn't even remotely correct that "any" method could raise > anything. If you can get something other than NameError, ValueError or > TypeError by calling "spam".index(arg), I'd like to see it. How common is it to call methods on a string literal in real-world code? It's far, far more common to call methods on an argument or expression whose value could be any "string-like object" (e.g. UserString or a str subclass). IOW, it's "almost" correct that any method can raise any exception. The fact that the number of counter-examples is non-zero doesn't really change this. Even an isinstance() check won't help, as nothing prohibits a subclass from raising exceptions which the original doesn't. Even using "type(x) == sometype" doesn't help if x's methods involve calling methods of user-supplied values (unless those methods are wrapped in catch-all excepts). Java's checked exception mechanism was based on real-world experience of the pitfalls of abstract types. And that experience was gained in environments where interface specifications were far more detailed than is the norm in the Python world. > Frankly, it sounds to me that you're over-analysing all the things that > "could" go wrong rather than focusing on the things that actually do go > wrong. See Murphy's Law. > That's your prerogative, of course, but I don't think you'll get > much support for it here. Alas, I suspect that you're correct. Which is why I don't advocate using Python for "serious" software. Neither the language nor its "culture" are amenable to robustness. -- http://mail.python.org/mailman/listinfo/python-list
