Re: [Python-Dev] Handle errors in cleanup code

2017-06-13 Thread Nathaniel Smith
On Tue, Jun 13, 2017 at 12:10 AM, Nick Coghlan wrote: > > reporting failures from concurrent.futures.wait: > https://pythonhosted.org/futures/#concurrent.futures.wait Yeah, and asyncio.gather is another example in the stdlib. Or there's twisted's DeferredList. Trio is unusual in effectively for

Re: [Python-Dev] Handle errors in cleanup code

2017-06-13 Thread Stefan Ring
On Tue, Jun 13, 2017 at 2:26 AM, Nathaniel Smith wrote: > On Mon, Jun 12, 2017 at 6:29 AM, Stefan Ring wrote: >> >> > Yury in the comment for PR 2108 [1] suggested more complicated code: >> > >> > do_something() >> > try: >> > do_something_other() >> > except BaseException as

Re: [Python-Dev] Handle errors in cleanup code

2017-06-13 Thread Nick Coghlan
On 13 June 2017 at 14:10, Nathaniel Smith wrote: > On Mon, Jun 12, 2017 at 1:07 AM, Nick Coghlan wrote: >> Since I don't see anything in the discussion so far that *requires* >> changes to the standard library (aside from "we may want to use this >> ourselves"), the right place to thrash out the

Re: [Python-Dev] Handle errors in cleanup code

2017-06-12 Thread Nathaniel Smith
On Mon, Jun 12, 2017 at 1:07 AM, Nick Coghlan wrote: > Aye, agreed. The key challenge we have is that we're trying to > represent the exception state as a linked list, when what we really > have once we start taking cleanup errors into account is an exception > *tree*. [...] > P.S. trio's MultiErr

Re: [Python-Dev] Handle errors in cleanup code

2017-06-12 Thread Nathaniel Smith
On Mon, Jun 12, 2017 at 6:29 AM, Stefan Ring wrote: > > > Yury in the comment for PR 2108 [1] suggested more complicated code: > > > > do_something() > > try: > > do_something_other() > > except BaseException as ex: > > try: > > undo_something() > >

Re: [Python-Dev] Handle errors in cleanup code

2017-06-12 Thread Brett Cannon
On Mon, 12 Jun 2017 at 01:08 Nick Coghlan wrote: > On 12 June 2017 at 17:31, Martin (gzlist) via Python-Dev > wrote: > > On 12/06/2017, Serhiy Storchaka wrote: > >> > >> But if an error is raised when execute undo_something(), it replaces the > >> original exception which become chaining as the

Re: [Python-Dev] Handle errors in cleanup code

2017-06-12 Thread Stefan Ring
> Yury in the comment for PR 2108 [1] suggested more complicated code: > > do_something() > try: > do_something_other() > except BaseException as ex: > try: > undo_something() > finally: > raise ex And this is still bad, because it loses

Re: [Python-Dev] Handle errors in cleanup code

2017-06-12 Thread Nick Coghlan
On 12 June 2017 at 17:31, Martin (gzlist) via Python-Dev wrote: > On 12/06/2017, Serhiy Storchaka wrote: >> >> But if an error is raised when execute undo_something(), it replaces the >> original exception which become chaining as the __context__ attribute. >> The problem is that this can change

Re: [Python-Dev] Handle errors in cleanup code

2017-06-12 Thread Nick Coghlan
On 12 June 2017 at 17:10, Serhiy Storchaka wrote: > Does it mean that we should rewrite every chunk of code similar to the > above? And if such cumbersome code is necessary and become common, maybe it > needs syntax support in the language? Or changing the semantic of exceptions > raised in error

Re: [Python-Dev] Handle errors in cleanup code

2017-06-12 Thread Martin (gzlist) via Python-Dev
On 12/06/2017, Serhiy Storchaka wrote: > > But if an error is raised when execute undo_something(), it replaces the > original exception which become chaining as the __context__ attribute. > The problem is that this can change the type of the exception. If > do_something_other() raises SystemExit

[Python-Dev] Handle errors in cleanup code

2017-06-12 Thread Serhiy Storchaka
There is an idiomatic Python code: do_something() try: do_something_other() except: undo_something() raise If an error is raised when execute do_something_other(), then we should first restore the state that was before calling do_something(), and then rerais