On Sat, Apr 11, 2020 at 9:30 PM Soni L. firstname.lastname@example.org wrote:
alternatively, they can let their caller handle it by having the espace come from the caller.
def bar(espace=None): x = foo(espace=espace)
and then the caller is expected to handle it, *if they so choose*.
If a function just replicates down the espace parameter, how is that even slightly different from the current situation? You STILL won't be able to know where the exception came from. I am at a complete loss to understand how all of this overhead (and there is a LOT of overhead) even solves the problem.
And if a function doesn't replicate it down, what exception space should it be using? How would it know?
we'll also need operator variants. I was thinking of the following:
x.in foo bar # for attribute access x[in foo bar] # for item access x +in foo bar # for math # etc
(yes, these are very ugly. this is one of the unfortunate things of trying to retrofit this into an existing language. but they're more likely to catch bugs so I'm not worried.)
I don't think they ARE more likely to catch bugs. You're making an incredibly ugly system that still has no indication that it'll help.
maybe this should be python 4. I don't think any language's ever done Rust-like explicit error handling (i.e. avoiding the issue of swallowing bugs) using exceptions before.
That'd be because mandatory explicit error handling is identical to mandatory return value checking, which is what you get in C and plenty of other languages. Exceptions don't give you any benefit if you have to check for them after every single function call.