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/ -- https://mail.python.org/mailman/listinfo/python-list