2017-06-23 17:09 GMT+02:00 Andy Dirnberger <dirn@dirnonline.com>:
It's not really a proposal. It's existing syntax.
Wow! I have been using Python since 1.5.2 and I never knew this. This is not Guido's famous time machine in action, by any chance? Guess there's some code to refactor using this construct now... Stephan 2017-06-23 17:09 GMT+02:00 Andy Dirnberger <dirn@dirnonline.com>:
Hi Stephan,
On Fri, Jun 23, 2017 at 6:23 AM, Stephan Houben <stephanh42@gmail.com> wrote:
Hi Andy,
What you propose is essentially the "try .. catch .. in" construct as described for Standard ML in:
It's not really a proposal. It's existing syntax. I was suggesting a way to implement the example that would catch an IndexError raised by accessing elements in bah but not those raised by foo.
https://pdfs.semanticscholar.org/b24a/60f84b296482769bb6752feeb3d93ba6aee8.p...
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.
Stephan
Andy
2017-06-23 1:47 GMT+02:00 Andy Dirnberger <dirn@dirnonline.com>:
On Jun 22, 2017, at 7:29 PM, Cameron Simpson <cs@zip.com.au> wrote:
On 23Jun2017 06:55, Steven D'Aprano <steve@pearwood.info> 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.
Consider:
try: foo(bah[5]) except IndexError as e: ... infer that there is no bah[5] ...
Of course, it is possible that bah[5] existed and that foo() raised an IndexError of its own. One might intend some sane handling of a missing bah[5] but instead silently conceal the IndexError from foo() by mishandling it as a missing bah[5].
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[5] in the example above, but _not_ catch an IndexError raised from deeper code such within the foo() function.
Something equivalent to:
try: foo(bah[5]) except IndexError as e: if e.__traceback__ not directly from the try..except lines: raise ... infer that there is no bah[5] ...
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[5] except IndexError: # handle your expected exception here else: foo(val)
Cheers, Cameron Simpson <cs@zip.com.au> _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/