How to pop the interpreter's stack?

[Steven D'Aprano]

On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:

>> Do you accept that, as a general principle, unhandled errors should be
>> reported as close as possible to where the error occurs? If your answer
>> to that is No, then where do you think unhandled errors should be
>> reported?
> 
> "No", and "where the error is detected".  That is, what Python does now.
>  Trying to figure out where the error "occurred" is fool's errand.

But isn't that what debugging is all about -- finding where the error 
occurred and fixing it? Hardly a fool's errand.


> The
> former isn't even well-defined, let alone something a compiler or user
> can be expected to reliably report.  Sometimes the error doesn't even
> "occur" in the same call stack.

Thank you for taking the time to respond. I think your objection misses 
the point I'm trying to make completely. But since this argument is 
rather academic, and it's Christmas Eve here, I'll just make one last 
comment and leave it at that:


> OTOH, going the extra mile to hide useful information from a user is
> asinine. As a user, I will decide for myself how I want to use
> implementation-defined information, and I don't want the implementor to
> decide this for me. It's bad enough if an implementor fails to provide
> information out of laziness, but when they deliberately do extra work to
> hide information, that's self-importance and arrogance.

But that of course is nonsense, because as the user you don't decide 
anything of the sort. The developer responsible for writing the function 
decides what information he provides you, starting with whether you get 
an exception at all, where it comes from, the type of exception, and the 
error message (if any). Once this information has been passed on to you, 
you're free to do anything you like with it, but you never get to choose 
what information you get -- I'm not suggesting any change there. 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.



-- 
Steven