Thanks Nicolai. I’ve opened an issue on phogbugz: https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-always-executed <https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-always-executed>.
> On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > 2016-08-08 8:52 GMT+02:00 Max Leske <maxle...@gmail.com > <mailto:maxle...@gmail.com>>: > Wow, that’s pretty bad. The process termination logic should be taking care > of the ensure blocks. Unfortunately I can’t run any Pharo images at the > moment but if there’s something wrong with process termination then it’s > likely that me or Ben made some mistake. Could someone please rerun Dale’s > test scenario with the original process termination code (e.g. from Pharo 3) > and report the results? > > Yes, test runs fine in pharo 30864 (halts in the ensure block) > > > Cheers, > Max > > > > On 8 Aug 2016, at 03:25, Dale Henrichs <dale.henri...@gemtalksystems.com > > <mailto:dale.henri...@gemtalksystems.com>> wrote: > > > > While attempting to characterize the "Empty Debugger" problem that I've > > recently reported[1], I found that ensure blocks in TestCase>>teardown > > methods are not run if an Error is signaled while executing the code > > protected by the ensure block ... when the test itself brings up a debugger > > --- now that is a mouthful :) ... but a situation that commonly occurs ... > > > > I've attached a fileIn with a very simple reproduction of this problem. > > After filing in the code, execute the following: > > > > BugTestCase debug: #test. > > > > Abandon the first halt -- this is the halt in the test. Next a debugger is > > brought up on the error from inside the ensure block in the tearDown method: > > > > tearDown > > [ self error: 'teardown' ] > > ensure: [ > > "Imagine that something important NEEDED to be done here" > > self halt ]. > > super tearDown. > > > > Abandon the error and the `self halt` in the ensure block is not run ... > > > > If you take the `self halt` out of the test method itself, the `self halt` > > in the ensure block _is_ run ... > > > > This does not directly lead to the Empty Debugger, but when the ensure > > blocks called during teardown are not run, a resource is not cleaned up > > properly and that leads to SharedQueue hanging ... when I interrupt the > > SharedQueue, I believe that this leads to the "Empty Debugger" a separate, > > but more nasty problem ... > > > > Dale > > > > [1] http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html > > <http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html> > > > > <BugTestCase.st> > > >
