Hi Marcel,
Halt is a breakpoint explicitly set in the source code.
In some way, Assertion could be viewed as conditional halt explicitly set
in the source code...
However, I don't like this POV. IMO AssertionFailure should not be subclass
of Halt.
Assertion failures are failure to fullfil some pre/post condition, and as
such programming Error.
I understand that Halt is just a way to invite users to debug programming
Error, but an Error works equally well.
Why using Halt?

Le lun. 11 nov. 2019 à 16:03, Marcel Taeumel <marcel.taeumel at hpi.de> a
écrit :

> Hi, there.
>
> The Kernel package provides "AssertionFailure" through "self assert: ...".
> The SUnit package provides "TestFailure" through "self assert: ..." in
> test cases.
>
> AssertionFailure is a subclass of Halt.
> TestFailure is a subclass of Exception.
>
> Now, the test runner catches all errors (red) and all test failures
> (yellow). However, the rest runner stops working if an AssertionFailure is
> raised. The Decompiler can do that, for example. In that case, the user
> cannot easily get an overview of all non-passing tests.
>
> Here are my questions:
>
> - Should AssertionFailure be an Error instead of a Halt?
> - Should SUnit treat "real" AssertionFailures also as errors (red)?
>
> Find attached two changesets with two different strategies.
>
> See TestResult >> #runCase: to see which exceptions are caught during test
> execution.
>
> Best,
> Marcel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191111/73d50ebe/attachment.html>