What you propose is essentially the "try .. catch .. in" construct as described for Standard ML in:
Something similar for Clojure is at: https://github.com/rufoa/try-let
So clearly this is something more people have struggled with. The paper above goes into deep detail on the practical and (proof-)theoretical advantages of such a construct.
2017-06-23 1:47 GMT+02:00 Andy Dirnberger email@example.com:
On Jun 22, 2017, at 7:29 PM, Cameron Simpson firstname.lastname@example.org wrote:
On 23Jun2017 06:55, Steven D'Aprano email@example.com wrote:
On Thu, Jun 22, 2017 at 10:30:57PM +0200, Sven R. Kunze wrote: We usually teach our newbies to catch exceptions as narrowly as possible, i.e. MyModel.DoesNotExist instead of a plain Exception. This works out quite well for now but the number of examples continue to grow where it's not enough.
(1) Under what circumstances is it not enough?
I believe that he means that it isn't precise enough. In particular, "nested exceptions" to me, from his use cases, means exceptions thrown from within functions called at the top level. I want this control too sometimes.
try: foo(bah) except IndexError as e: ... infer that there is no bah ...
Of course, it is possible that bah existed and that foo() raised an IndexError of its own. One might intend some sane handling of a missing bah but instead silently conceal the IndexError from foo() by mishandling it as a missing bah.
Naturally one can rearrange this code to call foo() outside that try/except, but that degree of control often leads to quite fiddly looking code with the core flow obscured by many tiny try/excepts.
One can easily want, instead, some kind of "shallow except", which would catch exceptions only if they were directly raised from the surface code; such a construct would catch the IndexError from a missing bah in the example above, but _not_ catch an IndexError raised from deeper code such within the foo() function.
Something equivalent to:
try: foo(bah) except IndexError as e: if e.__traceback__ not directly from the try..except lines: raise ... infer that there is no bah ...
There doesn't seem to be a concise way to write that. It might not even be feasible at all, as one doesn't have a way to identify the line(s) within the try/except in a form that one can recognise in a traceback.
How about something like this?
try: val = bah except IndexError: # handle your expected exception here else: foo(val)
Cheers, Cameron Simpson firstname.lastname@example.org _______________________________________________ Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/