> I wonder what was the reason for the special implementation in the first
> place. I assume it was to avoid the first debugger on the halt? Or was
> there any other reason? Did I miss something obvious?

No - I bet this is just more fall-out of the dreaded "run tests in 
background process" feature. Thanks for digging it up.

Cheers,
  - Andreas

----- Original Message ----- 
From: "Bernhard Pieber" <bernhard at pieber.com>
To: "Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, November 15, 2004 10:17 AM
Subject: [BUG][FIX] SUnit Unwind error during process termination


>I created a minimal test to show the "Unwind error during process
> termination" which haunted me the other day. See
> http://bugs.impara.de/bug_view_page.php?bug_id=0000501.
>
> "Change Set: UnwindErrorTest-bp
> Date: 15 November 2004
> Author: Bernhard Pieber
>
> This Change Set contains a TestCase which illustrates a problem with
> SUnit. Do the following:
> - Run UnwindErrorTest in SUnit Test Runner.
> - Click on the failing UnwindErrorTest>>#test. You get a debugger.
> - Click on Over. You get a second debugger.
> - Close this second debugger.
> - Close the first debugger. You get a third debugger: Unwind error
> during termination.
> - Closing this debugger does not work. You have to proceed."
>
> I assume that this behavior is a bug? I then compared the Squeak SUnit
> implementation with that of the other Smalltalks (VA, VW and Dolphin)
> and saw that it was different. I tried out what happens if I revert this
> to the standard implementations. It turns out that I cannot reproduce
> the Unwind error any more.
>
> "Change Set: SUnitDebugAsFailure-bp
> Date: 15 November 2004
> Author: Bernhard Pieber
>
> This Change Set reverts the implementation of debugAsFailure to the
> standard SUnit one. This has three effects:
> - When you debug a failing tests, you get a debugger on a halt. You have
> to proceed to get the Test failed debugger. This is not so nice.
> - The Test failed debugger runs to the failing assertion and not only to
> the first message send of the failing method. This is nice for test
> methods with many assertions.
> - The Unwind error during termination does not happen any more. See
> Change Set UnwindErrorTest-bp for details."
>
> All in all, it seems to me that the standard implementation is better
> for the following reasons:
> - It is the same like in at least three of the other dialects.
> - I could not reproduce the unwind error anymore.
> - While I have to proceed the first debugger with the halt, it then runs
> to the first failing assertion. So the number of clicks stays the same.
>
> I wonder what was the reason for the special implementation in the first
> place. I assume it was to avoid the first debugger on the halt? Or was
> there any other reason? Did I miss something obvious?
>
> Curiously,
> Bernhard
>


--------------------------------------------------------------------------------


>
>