use of Class Invariants

%u e at ee.com
Wed Dec 8 07:33:31 PST 2010


== Quote from Jonathan M Davis (jmdavisProg at gmx.com)'s article
> On Wednesday 08 December 2010 00:22:23 %u wrote:
> > At the moment most of my public member functions are littered with these
> > kind of in-out clauses.
> >
> > in{
> >   assert(wellformed, toString);
> > }
> > out{
> >   assert(wellformed, toString);
> > }
> >
> > They just beg for invariants, I though..
> > But invariants don't report the location of failure of contract, only the
> > location of failure within the invariant.
> > This seems kind of limiting. Am I missing something here?
> If an invariant fails, it throws an AssertError which will give you stack trace.
> That stack trace should include which function called the invariant. So, it
> _does_ tell you which function resulted in the invariant failing.
> - Jonathan M Davis
That is what I am missing, a stack trace.
How do I see a stack trace? dmd1(win)


More information about the Digitalmars-d-learn mailing list