[Tutor] please return flys in ointment

Steven D'Aprano steve at pearwood.info
Wed Jul 10 03:16:48 CEST 2013


On 10/07/13 04:05, Jim Mooney wrote:
> On 8 July 2013 18:16, Steven D'Aprano <steve at pearwood.info> wrote:
>>  I wouldn't even call it an Error, since it's actually a
>> limitation of Jim's code, not an actual error.
>
> Good point. But since I'm using try-except on input anyway, largely
> for int-checking, i figured why not use it? Putting in warn or
> something like that would just complicate matters.

Oh, I'm not saying you shouldn't use an exception. I'm just suggesting that you don't call it a Something-or-other-Error, since *internally* it is not a "bad data" error, but a "my function has a limitation" problem. Since the exception is only seen internally, it doesn't really matter though.

On the other hand, once you catch the Whatever-the-hell-it-gets-called exception, you treat it as if it were an error, by telling the user to try again. So I'm drawing a *really* fine line between errors and non-errors, and you may freely decide which side of the line to cut.

The real point I was hoping you would take from this is that exceptions are not necessarily *errors*. E.g.:

TypeError, ValueError, ZeroDivisionError -- all errors.

SystemExit, KeyboardInterrupt, StopIteration -- not errors.


Correct naming of exceptions are just as important as correct naming of functions and variables.



> I'm a chicken about input since webmasters have some demented people
> putting all sorts of odd javascript, PHP, and SQL into input to see if
> they can wreak some damage ;')

:-)


My advice is to split your code into two (or more) parts. The "engine", so to speak, should try it's best to handle anything you throw at it, although it may raise an exception or run for a very long time. E.g. if you type in 10**(10**100) (a googolplex), Python will try to calculate the answer, and probably fail with a MemoryError after an hour or so, if you are lucky. The second part faces the user, and acts as interface from the (trusted) engine to the (untrusted) user's data, and that's where you put in any additional restrictions validating user data.

That may seem like more work up front, but it pays off in the long run.



[...]
> Most American jurors are not told, by power-mad judges, that they can
> disregard the law, the evidence, and the instructions of the judge, if
> they feel a law is unfair, and render a verdict of "innocent". They
> are kept in the dark about this right, called Jury Nullification.

Completely off-topic, but I think it's unfair to describe them as "power-mad" because they have respect for the law, and incorrect to describe Jury Nullification as a *right*. A jury has *practical power* to ignore the law, since what goes on behind the closed doors of the jury room is sacrosanct and under American law judges and prosecutors have very limited power to inquire into why a jury decides to convict or not. But that's not a legal right, any more than I have the legal right to slander you provided you don't find out about it. It's more like civil disobedience than an explicit right granted to jurors.

But consider that Jury Nullification is a dangerous power to wield. Jury nullification has been used to protect escaped slaves from being returned to their slave owners, and to allow racists to commit racially-motivated murder with impunity. It's a double-edged sword, and there's no reason to assume that justice will always be served by encouraging jurors to ignore the law.

-- 
Steven


More information about the Tutor mailing list