raise None

[Martin A. Brown]

Hi there,

>>> At worst it actively misleads the user into thinking that there 
>>> is a bug in _validate.

Is this "user" a software user or another programmer?

If a software user, then some hint about why the _validate found 
unacceptable data might benefit the user's ability to adjust inputs 
to the program.

If another programmer, then that person should be able to figure it 
out with the full trace.  Probably it's not a bug in _validate, but 
....it could be.  So, it could be a disservice to the diagnostician 
to exempt the _validate function from suspicion.  Thus, I'd want to 
see _validate in the stack trace.

>Maybe. As I have suggested a number of times now, I'm aware that 
>this is just a marginal issue.
>
>But I think it is a real issue. I believe in beautiful tracebacks 
>that give you just the right amount of information, neither too 
>little nor two much. Debugging is hard enough with being given more 
>information than you need and having to decide what bits to ignore 
>and which are important.

I agree about tracebacks that provide the right amount of 
information.  If I were a programmer working with the code you are 
describingi, I would like to know in any traceback that the failed 
comparisons (which implement some sort of business logic or sanity 
checking) occurred in the _validate function.

In any software system beyond the simplest, code/data tracing would 
be required to figure out where the bad data originated.

Since Python allows us to provide ancillary text to any exception, 
you could always provide a fuller explanation of the validation 
failure.  And, while you are at it, you could add the calling 
function name to the text to point the programmer faster toward the 
probable issue.

Adding one optional parameter to _validate (defaulting to the 
caller's function name) would allow you to point the way to a 
diagnostician.  Here's a _validate function I made up with two silly 
comparision tests--where a must be greater than b and both a and b 
must not be convertible to integers.

  def _validate(a, b, func=None):
    if not func:
        func = sys._getframe(1).f_code.co_name
    if a >= b:
        raise ValueError("a cannot be larger than b in " + func)
    if a == int(a) or b == int(b):
        raise TypeError("a, b must not be convertible to int in " + func)

My main point is less about identifying the calling function or its 
calling function, but rather to observe that arbitrary text can be 
used.  This should help the poor sap (who is, invariably, diagnosing 
the problem at 03:00) realize that the function _validate is not the 
problem.

>The principle is that errors should be raised as close to their 
>cause as possible. If I call spam(a, b) and provide bad arguments, 
>the earliest I can possibly detect that is in spam. (Only spam 
>knows what it accepts as arguments.) Any additional levels beyond 
>spam (like _validate) is moving further away:
>
>  File "spam", line 19, in this
>  File "spam", line 29, in that      <--- where the error really lies
>  File "spam", line 39, in other
>  File "spam", line 89, in spam      <--- the first place we could detect it
>  File "spam", line 5, in _validate  <--- where we actually detect it

Yes, indeed!  Our stock in trade.  I never liked function 'that'.  I 
much prefer function 'this'.

-Martin

  Q:  Who is Snow White's brother?
  A:  Egg white.  Get the yolk?

-- 
Martin A. Brown
http://linux-ip.net/