[Swift-devel] assertion behavior

[Mihael Hategan]

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