How to pop the interpreter's stack?

[John Nagle]

On 12/25/2010 2:50 PM, Steven D'Aprano wrote:
> 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.

     No, that is the issue, unless the program itself is examining the
stack traceback data.  Python exception-catching has no notion of
what code raised the exception. Only the contents of the exception
object are normally available.   So the "private function" is always
"hidden", unless you're debugging, in which case it shouldn't be
hidden.

     Traceback is purely a debugging feature.  In some Python
implementations, such as Shed Skin, you don't get tracebacks unless
you're running under a debugger.

					John Nagle