Unicode error

[Nobody]

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.