How to pop the interpreter's stack?

Steven D'Aprano steve+comp.lang.python at pearwood.info
Sat Dec 25 17:50:00 EST 2010


On Fri, 24 Dec 2010 10:51:32 -0800, John Nagle wrote:

> On 12/24/2010 3:24 AM, Carl Banks wrote:
>> On Dec 24, 1:24 am, Steven D'Aprano<steve
>> +comp.lang.pyt... at pearwood.info>  wrote:
>   All I'm
>>> suggesting is that there should be a way of reducing the boilerplate
>>> needed for this idiom:
>>>
>>> def _validate_arg(x):
>>>      if x == 'bad input': return False
>>>      return True
>>>
>>> def f(arg):
>>>      if not _validate_arg(arg):
>>>          raise ValueError
>>>      process(arg)
>>>
>>> to something more natural that doesn't needlessly expose
>>> implementation details that are completely irrelevant to the caller.
> 
>      How about
> 
> 	raise ValueError("Bad input %s to validate_arg" % (repr(arg),))
> 
> You can pass arguments to most exceptions, and the content of the
> exception is determined entirely by the code raising it.

I know that exceptions can take arguments (usually string error 
messages). I was writing in short-hand. My apologies, I thought that 
would have been obvious :(

Perhaps you have missed the context of the discussion. The context is 
that the called function delegates the job of validating input to a 
private function, which should be hidden from the caller (it's private, 
not part of the public API, subject to change, hidden, etc.) but 
tracebacks expose that information, obscuring the cause of the fault. 
(The fault being bad input to the public function, not an accidental bug 
in the private function.)


> If end users are seeing uncaught tracebacks, the program is broken.

Well, perhaps, but that's a separate issue. We're talking about the 
caller of the function seeing internal details, not the end use.



-- 
Steven



More information about the Python-list mailing list