Can I register yet another request for this long-looked-for feature?

I'm finding it rather painful that the output just prints "Error: AssertError Failure vector(390)". It's just a PITA.

Can we get this for 1.0?

In article <cd077b$282s$1@digitaldaemon.com>, Matthew Wilson says...
>
>Can I register yet another request for this long-looked-for feature?
>
>I'm finding it rather painful that the output just prints "Error: AssertError Failure vector(390)". It's just a PITA.
>
>Can we get this for 1.0?



You could always do what I do these days, which is to replace:

#    assert(a == b);

with

#    if (a != b) throw new Error("a is not equal to b in function f()");

or similar. Actually, I've never been entirely comfortable with assert()s, since they magically disappear in a release build. This is a good thing only if you're sure those asserts are never going to happen.

Jill

Matthew Wilson wrote:

>Can I register yet another request for this long-looked-for feature?
>
>I'm finding it rather painful that the output just prints "Error:
>AssertError Failure vector(390)". It's just a PITA.
>
>Can we get this for 1.0?
>
>
>  
>
Yes, please.

Speaking of asserts, another useful feature would be a continue (ie ignore/ignore all) option.  That is particularly useful when working in a large group of people and someone stuffs up part of the build that is not very important to you (ie you working on graphics and someone stuff up the sound engine).  Although I'm not exactly sure how that would work though. 

I think the best option (parhaps 2.0) is to allow for our own customisable asserts. That way we can stop things like timers, things over networks and graphics cards and re-start them again when continued.  We can then also put up a nice OS based interface to deal with asserts.  That is the safest option.

-- 
-Anderson: http://badmama.com.au/~anderson/

void myAssert(bit condition, char[] message)
{
	if (condition)
		throw new myException(message);
}

I'm not sure what it is you're looking for that can't be done with Exceptions.

On Tue, 13 Jul 2004 23:34:37 +0800, J Anderson wrote:

> Matthew Wilson wrote:
> 
>>Can I register yet another request for this long-looked-for feature?
>>
>>I'm finding it rather painful that the output just prints "Error: AssertError Failure vector(390)". It's just a PITA.
>>
>>Can we get this for 1.0?
>>
>>
>>
>> 
> Yes, please.
> 
> Speaking of asserts, another useful feature would be a continue (ie ignore/ignore all) option.  That is particularly useful when working in a large group of people and someone stuffs up part of the build that is not very important to you (ie you working on graphics and someone stuff up the sound engine).  Although I'm not exactly sure how that would work though.
> 
> I think the best option (parhaps 2.0) is to allow for our own customisable asserts. That way we can stop things like timers, things over networks and graphics cards and re-start them again when continued.  We can then also put up a nice OS based interface to deal with asserts.  That is the safest option.

On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson <dmd@synesis.com.au> wrote:
> Can I register yet another request for this long-looked-for feature?
>
> I'm finding it rather painful that the output just prints "Error:
> AssertError Failure vector(390)". It's just a PITA.
>
> Can we get this for 1.0?

I can't see the point myself.

asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted.

That said, when you do something like..

foreach(char[] s; testStrings)
{
  ..etc..
  assert();
}

the file/line number for the assert does not tell you which testString failed.

In which case I have used:

foreach(char[] s; testStrings)
{
  ..etc..
  if () {
    printf("");
    assert();
  }
}

While on this topic, what does an assert do in a windows full screen 3d app? currently, I assume, it is printing to stderr and terminating the app. Can we over-ride that behaviour?

I imagine a full screen 3d app does not have a console or a stderr, plus you want the assert box to popup in front of the full screen display. I have seen commercial games where the error box was hidden by the games main window with no way to see it.

I think a global onAssert() method/function that if exists is called on assert would be very useful.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa3k2sce5a2sq9@digitalmars.com...
> On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson <dmd@synesis.com.au> wrote:
> > Can I register yet another request for this long-looked-for feature?
> >
> > I'm finding it rather painful that the output just prints "Error: AssertError Failure vector(390)". It's just a PITA.
> >
> > Can we get this for 1.0?
>
> I can't see the point myself.
>
> asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted.

Nonsense. What about users of libraries, i.e. developers?

Look through the STLSoft source - in fact grep for "message_assert" - and you'll see just how useful a meaningful message in an assertion can be.

On Wed, 14 Jul 2004 10:07:39 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsa3k2sce5a2sq9@digitalmars.com...
>> On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson <dmd@synesis.com.au>
>> wrote:
>> > Can I register yet another request for this long-looked-for feature?
>> >
>> > I'm finding it rather painful that the output just prints "Error:
>> > AssertError Failure vector(390)". It's just a PITA.
>> >
>> > Can we get this for 1.0?
>>
>> I can't see the point myself.
>>
>> asserts only occur in debug builds, so end users never see them, so it's
>> only you the developer that sees them, in which case you simply open the
>> source and you can see what asserted.
>
> Nonsense. What about users of libraries, i.e. developers?

Open source or closed? If it's open source you can open the source and look.

> Look through the STLSoft source - in fact grep for "message_assert" - and you'll
> see just how useful a meaningful message in an assertion can be.

The fact that I can, tells me this is open source, in which case if I got an assert I could open the source and look.

Regardless, can you give me an example of when your library would assert. Is it because I called a function with incorrect parameters? or..?

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa3p7mzu5a2sq9@digitalmars.com...
> On Wed, 14 Jul 2004 10:07:39 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa3k2sce5a2sq9@digitalmars.com...
> >> On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson <dmd@synesis.com.au> wrote:
> >> > Can I register yet another request for this long-looked-for feature?
> >> >
> >> > I'm finding it rather painful that the output just prints "Error: AssertError Failure vector(390)". It's just a PITA.
> >> >
> >> > Can we get this for 1.0?
> >>
> >> I can't see the point myself.
> >>
> >> asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted.
> >
> > Nonsense. What about users of libraries, i.e. developers?
>
> Open source or closed? If it's open source you can open the source and look.

Yes, but sometimes the assert condition can be complex. If there's a simple message telling the user immediately what the problem is, then they've saved time. I can't see why that's not an attractive thing? It helps in many circumstances, but costs nothing and does no harm.

Matthew wrote:

> 
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa3p7mzu5a2sq9@digitalmars.com...
>> On Wed, 14 Jul 2004 10:07:39 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa3k2sce5a2sq9@digitalmars.com...
>> >> On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson <dmd@synesis.com.au> wrote:
>> >> > Can I register yet another request for this long-looked-for feature?
>> >> >
>> >> > I'm finding it rather painful that the output just prints "Error: AssertError Failure vector(390)". It's just a PITA.
>> >> >
>> >> > Can we get this for 1.0?
>> >>
>> >> I can't see the point myself.
>> >>
>> >> asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted.
>> >
>> > Nonsense. What about users of libraries, i.e. developers?
>>
>> Open source or closed? If it's open source you can open the source and look.
> 
> Yes, but sometimes the assert condition can be complex. If there's a simple message telling the user immediately what the problem is, then they've saved time. I can't see why that's not an attractive thing? It helps in many circumstances, but costs nothing and does no harm.

Here are a few message_assert's I've found in src/phobos/etc/c/stlsoft:

 winstl_message_assert("Attempting to increment an invalid iterator!", NULL
!= m_handle);

 winstl_message_assert("Dereferencing end()-valued iterator", 0);

 unixstl_message_assert("Shared search handle being destroyed with
outstanding references!", 0 == cRefs);

and it looks generally like these asserts are for cases when the user has incorrectly used the library. I agree for these types of asserts (if they should be asserts) a message helps the user correct their code. But a typical assert Walter uses is something like

 Internal Error: ..\ztc\cgcod.c 614

which means Walter (not the user) messed up and all he needs are some
reproduction steps and the file and line number. Personally I tend to use
asserts like you do and consider invalid usage to be assertable where
Walter keeps asserts to only internal usage (I think Arcane Jill had also
posted that's how she uses asserts). So I think it makes sense to have two
different assert mechanisms for these two different usage models.
Maybe there should be some sort of "private assert" and "public assert" and
the public one has message strings and the private one doesn't.

-Ben

On Wed, 14 Jul 2004 11:12:44 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsa3p7mzu5a2sq9@digitalmars.com...
>> On Wed, 14 Jul 2004 10:07:39 +1000, Matthew
>> <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> > "Regan Heath" <regan@netwin.co.nz> wrote in message
>> > news:opsa3k2sce5a2sq9@digitalmars.com...
>> >> On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson 
>> <dmd@synesis.com.au>
>> >> wrote:
>> >> > Can I register yet another request for this long-looked-for 
>> feature?
>> >> >
>> >> > I'm finding it rather painful that the output just prints "Error:
>> >> > AssertError Failure vector(390)". It's just a PITA.
>> >> >
>> >> > Can we get this for 1.0?
>> >>
>> >> I can't see the point myself.
>> >>
>> >> asserts only occur in debug builds, so end users never see them, so 
>> it's
>> >> only you the developer that sees them, in which case you simply open 
>> the
>> >> source and you can see what asserted.
>> >
>> > Nonsense. What about users of libraries, i.e. developers?
>>
>> Open source or closed? If it's open source you can open the source and
>> look.
>
> Yes, but sometimes the assert condition can be complex. If there's a simple
> message telling the user immediately what the problem is, then they've saved
> time. I can't see why that's not an attractive thing? It helps in many
> circumstances, but costs nothing and does no harm.

The cost is Walters time, the other features/things he does not do while he is doing this.
Is this really something you *must* have for 1.0? or is it simply decoration.

I think it's decoration as you can already get a 'nice' message by printing then asserting.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/