Hi Stephan, On Fri, Jun 23, 2017 at 6:23 AM, Stephan Houben <stephan...@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/60f84b296482769bb6752feeb3d93b > a6aee8.pdf > > 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 <d...@dirnonline.com>: > > > > > >> On Jun 22, 2017, at 7:29 PM, Cameron Simpson <c...@zip.com.au> wrote: > >> > >>> On 23Jun2017 06:55, Steven D'Aprano <st...@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 <c...@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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
