Unicode error

[Steven D'Aprano]

On Sun, 25 Jul 2010 13:52:33 +0100, Nobody wrote:

> On Fri, 23 Jul 2010 18:27:50 -0400, Terry Reedy 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"? Do you mean like power 
supply fluctuations, cosmic rays flipping bits in memory, bad hardware? 
You can't defend against that, not without specialist fault-tolerant 
hardware, so just don't worry about it.

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.

Or don't worry about it. Release early, release often, and take lots of 
logs. You'll soon learn what exceptions can happen and what can't. Your 
software is still useful even when it's not perfect, and there's always 
time for another bug fix release.


> 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. You can reject it with an exception, 
stick it inside a wrapper object, convert it to something else, deal with 
it as best you can, or just ignore it.


> 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. 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.

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. That's your prerogative, of course, but I don't think you'll get 
much support for it here.



-- 
Steven