On 2020-04-11 1:01 p.m., David Mertz wrote:
It sounds like you've entirely missed the point of Python exceptions. You are right that they are a kind of dynamic scope. That's their entire reason for existing, not a bug.
In Python, we can handle an exception at the particular scope in which it is most appropriate and useful to handle it, and not worry about it elsewhere.
On the very rare occasions where I've stumbled on an exception being raised "for the wrong reason" the solution is ALWAYS either to make try/except surround less, or to subclass exceptions to be more specific.
If some library or framework is unwilling to subclass, they will be that much less willing to add special, very fragile, syntax for the same purpose.
the reason I'm proposing this is that I like standard exception types having well-defined semantics. this "special, very fragile, syntax for the same purpose" doesn't take away from that, and instead just adds to it.
it's a way of having multiple, independent, "local" dynamic scopes. instead of just one global dynamic scope. and enables you to freely use standard exception types.
if anything it's closer to passing in a namespace with a bunch of standard exception types every time you wanna do stuff. which... I could also get behind tbh. an stdlib addition that dynamically exposes subclasses of the standard exception types, unique to that namespace instance. would still need some way of passing it in to operators and stuff tho.
On Sat, Apr 11, 2020, 11:37 AM Soni L.
I'm not saying rust has the best solution. I don't like how it's so explicit about error handling. sometimes letting it bubble up is great. but rust doesn't have the problem of exception handling being inherently dangerous, context-sensitive, and destructive to application logic. python's exception handling is effectively a form of dynamic scoping, as defined by wikipedia: "In some languages, however, "part of a program" refers to "portion of run time (time period during execution)", and is known as *dynamic scope*.".