[Swift-devel] assertion behavior

[Justin M Wozniak]

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