On Fri, Apr 08, 2016 at 11:24:15AM -0700, email@example.com wrote:
I want to live in a world where I can do this:
cb = cbs.pop()
except Exception as e:
logging.exception("In main loop")
raise SystemExit() from e
And I want a pony :-)
So long as Python allows people to write code like this:
# A deliberately silly example
if len(seq) == 0:
raise ImportError("assertion fails")
you cannot expect to automatically know what an exception means without
any context of where it came from and why it happened. The above example
is silly, but it doesn't take much effort to come up with more serious
- an interpreter written in Python may raise SyntaxError, which
is not a bug in the interpreter;
- a test framework may raise AssertionError for a failed test,
which is not a bug in the framework;
- a function may raise MemoryError if the call *would* run out of
memory, but without actually running out of memory; consequently
it is not a fatal error, while another function may raise the
same MemoryError because it actually did fatally run out of memory.
Effectively, you want the compiler to Do What I Mean when it comes to
exceptions. DWIM may, occasionally, be a good idea in applications, but
I maintain it is never a good idea in a programming language.
I think you're misinterpreting me. I don't want a pony and I don't want a sufficiently smart compiler.
I want a consistent opt-in idiom with community consensus. I want a clear way to express that an exception is an error and not an internal bug. It doesn't have to catch 100% of cases, the idiom just needs to approach consistency across all Python libraries that I may import.
If the programmer doesn't pay attention to the idiom, then is_a_bug() will never return true (or not True if it's is_not_a_bug()). AssertionError is already unambiguous, I'm sure there are other candidates as well.
But I can see the pile on has begun and my point is lost. Maybe this will get added in ten or twenty years.