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