[Swift-devel] assertion behavior

Tim Armstrong tim.g.armstrong at gmail.com
Tue Mar 31 11:30:07 CDT 2015 

I think Swift application testing has fairly different requirements from
what traditional assertions provide.

Hard aborts work well for the language testing since if there are a
language-level bugs we have no idea what state things are left in from test
to test. They also work well for catching logic errors in programs (the
classic use case for asserts).

I think if you want to build SwiftUnit (or whatever it would be called), it
would probably need to use different mechanisms from the regular asserts.

- Tim

On 31 March 2015 at 10:25, Justin M Wozniak <wozniak at mcs.anl.gov> wrote:

>
> If assert failure always returns control to the OS, should we use some
> other symbol in the test suite?  Or is managing testable code from Swift a
> bad idea?  (This isn't just about core Swift tests, this is about
> supporting test-driven development in Swift.)
>
>
> On 03/28/2015 12:43 AM, Mihael Hategan wrote:
>
>> Right. I also think that a hard abort is the right choice. An assertion
>> is a fundamental statement about program correctness. If that fails,
>> there shouldn't be much of a point in continuing.
>>
>> In other news, we still need some kind of fault isolation and handling
>> mechanism.
>>
>> Mihael
>>
>> On Fri, 2015-03-27 at 21:58 -0500, Tim Armstrong wrote:
>>
>>> I feel like that is getting away from what assertions are intended to be
>>> -
>>> the best thing about them is that they're dead simple and have a clear,
>>> well-defined use case.  I don't think that should be compromised out of a
>>> desire to have them serve dual purposes.
>>>
>>> - Tim
>>>
>>> On 27 March 2015 at 12:28, Justin M Wozniak <wozniak at mcs.anl.gov> wrote:
>>>
>>>  Catchable/soft assertion failures would be useful if we rewrote the test
>>>> suite in Swift.  Maybe we should do that anyway.
>>>>
>>>> On 3/27/2015 9:39 AM, Tim Armstrong wrote:
>>>>
>>>>   I don't think it makes sense to treat it as a soft error.
>>>>
>>>> The primary use case for assertions is the Swift/T test suite and
>>>> there's
>>>> no reason to continue running after an assertion failure.
>>>>
>>>> If a user wants to use them in their own scripts, they're intended to
>>>> catch bugs or unintended behaviour.  If an assertion fails, the script
>>>> is
>>>> not doing what it's meant to be doing.  I don't see any reason to keep
>>>> on
>>>> running a buggy script that failed an assertion, and I see plenty of
>>>> reasons not to keep it running.
>>>>
>>>>   If users want to disable their assertions there is support for that.
>>>>
>>>>   - Tim
>>>>
>>>> On 27 March 2015 at 09:20, Michael Wilde <wilde at anl.gov> wrote:
>>>>
>>>>    Does "terminate immediately" need to always be immediate or
>>>>> should/could
>>>>> it integrate with the Swift/K notion of "soft errors"?
>>>>>
>>>>> I.e. an assert failure is treated like a failing function; that in turn
>>>>> as handled as the soft-error property specifies.
>>>>> - Mike
>>>>>
>>>>>
>>>>>
>>>>> On 3/25/15 10:24 PM, Tim Armstrong wrote:
>>>>>
>>>>>   The program terminates immediately with an error message.
>>>>>
>>>>> There's a compile-time option to disable assertions if needed.  It's
>>>>> actually a little weird in that it syntactically removes the statement
>>>>> - it
>>>>> doesn't evaluate the arguments to the funciton.
>>>>>
>>>>>   - Tim
>>>>>
>>>>> On 25 March 2015 at 22:09, Mihael Hategan <hategan at mcs.anl.gov> wrote:
>>>>>
>>>>>  Hi,
>>>>>>
>>>>>> In Swift/T, what happens when an assertion fails?
>>>>>>
>>>>>> Mihael
>>>>>>
>>>>>> _______________________________________________
>>>>>> Swift-devel mailing list
>>>>>> Swift-devel at ci.uchicago.edu
>>>>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Swift-devel mailing listSwift-devel at ci.uchicago.eduhttps://
>>>>> lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>>>
>>>>>
>>>>>    --
>>>>> Michael Wilde
>>>>> Mathematics and Computer Science          Computation Institute
>>>>> Argonne National Laboratory               The University of Chicago
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Swift-devel mailing list
>>>>> Swift-devel at ci.uchicago.edu
>>>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Swift-devel mailing listSwift-devel at ci.uchicago.eduhttps://
>>>> lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Justin M Wozniak
>>>>
>>>>
>>>>  _______________________________________________
>>> Swift-devel mailing list
>>> Swift-devel at ci.uchicago.edu
>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>
>>
>>
>
> --
> Justin M Wozniak
>
>

On 31 March 2015 at 10:25, Justin M Wozniak <wozniak at mcs.anl.gov> wrote:

>
> If assert failure always returns control to the OS, should we use some
> other symbol in the test suite?  Or is managing testable code from Swift a
> bad idea?  (This isn't just about core Swift tests, this is about
> supporting test-driven development in Swift.)
>
>
> On 03/28/2015 12:43 AM, Mihael Hategan wrote:
>
>> Right. I also think that a hard abort is the right choice. An assertion
>> is a fundamental statement about program correctness. If that fails,
>> there shouldn't be much of a point in continuing.
>>
>> In other news, we still need some kind of fault isolation and handling
>> mechanism.
>>
>> Mihael
>>
>> On Fri, 2015-03-27 at 21:58 -0500, Tim Armstrong wrote:
>>
>>> I feel like that is getting away from what assertions are intended to be
>>> -
>>> the best thing about them is that they're dead simple and have a clear,
>>> well-defined use case.  I don't think that should be compromised out of a
>>> desire to have them serve dual purposes.
>>>
>>> - Tim
>>>
>>> On 27 March 2015 at 12:28, Justin M Wozniak <wozniak at mcs.anl.gov> wrote:
>>>
>>>  Catchable/soft assertion failures would be useful if we rewrote the test
>>>> suite in Swift.  Maybe we should do that anyway.
>>>>
>>>> On 3/27/2015 9:39 AM, Tim Armstrong wrote:
>>>>
>>>>   I don't think it makes sense to treat it as a soft error.
>>>>
>>>> The primary use case for assertions is the Swift/T test suite and
>>>> there's
>>>> no reason to continue running after an assertion failure.
>>>>
>>>> If a user wants to use them in their own scripts, they're intended to
>>>> catch bugs or unintended behaviour.  If an assertion fails, the script
>>>> is
>>>> not doing what it's meant to be doing.  I don't see any reason to keep
>>>> on
>>>> running a buggy script that failed an assertion, and I see plenty of
>>>> reasons not to keep it running.
>>>>
>>>>   If users want to disable their assertions there is support for that.
>>>>
>>>>   - Tim
>>>>
>>>> On 27 March 2015 at 09:20, Michael Wilde <wilde at anl.gov> wrote:
>>>>
>>>>    Does "terminate immediately" need to always be immediate or
>>>>> should/could
>>>>> it integrate with the Swift/K notion of "soft errors"?
>>>>>
>>>>> I.e. an assert failure is treated like a failing function; that in turn
>>>>> as handled as the soft-error property specifies.
>>>>> - Mike
>>>>>
>>>>>
>>>>>
>>>>> On 3/25/15 10:24 PM, Tim Armstrong wrote:
>>>>>
>>>>>   The program terminates immediately with an error message.
>>>>>
>>>>> There's a compile-time option to disable assertions if needed.  It's
>>>>> actually a little weird in that it syntactically removes the statement
>>>>> - it
>>>>> doesn't evaluate the arguments to the funciton.
>>>>>
>>>>>   - Tim
>>>>>
>>>>> On 25 March 2015 at 22:09, Mihael Hategan <hategan at mcs.anl.gov> wrote:
>>>>>
>>>>>  Hi,
>>>>>>
>>>>>> In Swift/T, what happens when an assertion fails?
>>>>>>
>>>>>> Mihael
>>>>>>
>>>>>> _______________________________________________
>>>>>> Swift-devel mailing list
>>>>>> Swift-devel at ci.uchicago.edu
>>>>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Swift-devel mailing listSwift-devel at ci.uchicago.eduhttps://
>>>>> lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>>>
>>>>>
>>>>>    --
>>>>> Michael Wilde
>>>>> Mathematics and Computer Science          Computation Institute
>>>>> Argonne National Laboratory               The University of Chicago
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Swift-devel mailing list
>>>>> Swift-devel at ci.uchicago.edu
>>>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Swift-devel mailing listSwift-devel at ci.uchicago.eduhttps://
>>>> lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Justin M Wozniak
>>>>
>>>>
>>>>  _______________________________________________
>>> Swift-devel mailing list
>>> Swift-devel at ci.uchicago.edu
>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>
>>
>>
>
> --
> Justin M Wozniak
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150331/6650a267/attachment.html>

More information about the Swift-devel mailing list