Thank you all for taking care and feeling like Pharo is your baby :).
Stef
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.
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@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
> <BugTestCase.st>
> On 8 Aug 2016, at 03:25, Dale Henrichs <dale.henrichs@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
>