www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Error: AssertError Failure

reply Kixdemp <Kixdemp_member pathlink.com> writes:
Hello everyone! :-D
OK, look at my code:

------------------------
import std.c.windows.windows;

extern (Windows) bool Beep(uint, uint);

int main(char[][] args)
{
Beep(100, 100);
}
------------------------

It compiles witn no errors, but when I run it:

Error: AssertError Failure test.d(8)

Anyonw know why? Thanks! ;-)
Dec 04 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Kixdemp" <Kixdemp_member pathlink.com> wrote in message 
news:dn0c1i$2iun$1 digitaldaemon.com...

 It compiles witn no errors, but when I run it:

 Error: AssertError Failure test.d(8)

 Anyonw know why? Thanks! ;-)


You've defined main() to return an int, but you never return anything. 
Instead of a compiler error, D makes a return-value-less function a runtime 
error.  More than once I've wished that the error message would be a little 
more specific..
Dec 04 2005
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Sun, 04 Dec 2005 22:30:16 -0500, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:


 "Kixdemp" <Kixdemp_member pathlink.com> wrote in message
 news:dn0c1i$2iun$1 digitaldaemon.com...

 It compiles witn no errors, but when I run it:

 Error: AssertError Failure test.d(8)

 Anyonw know why? Thanks! ;-)


 You've defined main() to return an int, but you never return anything.
 Instead of a compiler error, D makes a return-value-less function a  
 runtime
 error.  More than once I've wished that the error message would be a  
 little
 more specific..


Compile with -w
Dec 04 2005
next sibling parent Kixdemp <Kixdemp_member pathlink.com> writes:
In article <op.s1aj50qapo9bzi dialup-4.157.44.14.dial1.boston1.level3.net>,
Chris Miller says...

On Sun, 04 Dec 2005 22:30:16 -0500, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:


 "Kixdemp" <Kixdemp_member pathlink.com> wrote in message
 news:dn0c1i$2iun$1 digitaldaemon.com...

 It compiles witn no errors, but when I run it:

 Error: AssertError Failure test.d(8)

 Anyonw know why? Thanks! ;-)


 You've defined main() to return an int, but you never return anything.
 Instead of a compiler error, D makes a return-value-less function a  
 runtime
 error.  More than once I've wished that the error message would be a  
 little
 more specific..


Compile with -w


Thanks very much! ;-)
Dec 04 2005
prev sibling parent reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
Chris Miller schrieb:



 On Sun, 04 Dec 2005 22:30:16 -0500, Jarrett Billingsley
 <kb3ctd2 yahoo.com> wrote:
 

 "Kixdemp" <Kixdemp_member pathlink.com> wrote in message
 news:dn0c1i$2iun$1 digitaldaemon.com...

 It compiles witn no errors, but when I run it:

 Error: AssertError Failure test.d(8)

 Anyonw know why? Thanks! ;-)


 You've defined main() to return an int, but you never return anything.
 Instead of a compiler error, D makes a return-value-less function a
 runtime
 error.  More than once I've wished that the error message would be a
 little
 more specific..




I agree! Something like "ERROR: no return value" would be much nicer!

Tiago

-- 
Tiago Gasiba (M.Sc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
Dec 05 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Tiago Gasiba wrote:


Error: AssertError Failure test.d(8)

Anyonw know why? Thanks! ;-)


You've defined main() to return an int, but you never return anything.
Instead of a compiler error, D makes a return-value-less function a
runtime
error.  More than once I've wished that the error message would be a
little
more specific..




 
 I agree! Something like "ERROR: no return value" would be much nicer!


The compiler just inserts an "assert(0);" line,
and assert doesn't allow for any such messages...
e.g. assert(false,"no return at end of function");

func.c(689):
	if (global.params.warnings)
	{	printf("warning - ");
	error("no return at end of function");
	}

	if (global.params.useAssert &&
	!global.params.useInline)
	{   /* Add an assert(0); where the missing return
	 * should be.
	 */
	e = new AssertExp(endloc, new IntegerExp(0, 0, Type::tint32));
	}
	else
	e = new HaltExp(endloc);

Side note: in the above code you can see that if
you use -inline, then you'll get a "halt" instead!
Same if you use -release, which disables all asserts.



This is an oft-requested D feature, that
assert() is allowed to take messages too.

You can do this in Java, for instance:
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

But so far it has been rejected, for D...


I think it's similar to "Access Violation",
which isn't guarded especially for either.

In Java, you would get a NullPointerException
with the stack trace of the callers (catchable).

In D, it's time to bring out the debugger...


Don't think it's going to change any time soon: source file/line it is.
(In the original posting, the AssertError does point to the "}" line...)

I just think Walter prefers* the "hard" errors, pointing to the source ?

--anders


* http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2165
   http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14466
Dec 05 2005
next sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
 Don't think it's going to change any time soon: source file/line it is.
 (In the original posting, the AssertError does point to the "}" line...)

 I just think Walter prefers* the "hard" errors, pointing to the source ?


Indeed, he does. And although I have created an "assert2(int,const char*)" 
myself in my current project, I have to agree with Walter on this one.

What would be handy though is the expression appearing in the assert error 
message. Then you could write "int no_return_value; 
assert(no_return_value);" and the printed message would contain 
"no_return_value" as a hint.

L.
Dec 05 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:


 What would be handy though is the expression appearing in the assert error 
 message. Then you could write "int no_return_value; 
 assert(no_return_value);" and the printed message would contain 
 "no_return_value" as a hint.


You mean like how the usual #define of assert works, in C ?

#define assert(expr)  \
   ((void) ((expr) ? 0 : __assert (#expr, __FILE__, __LINE__)))

Not that there any messages, but one could do something like:

	bool no_return_value = false;
	assert(no_return_value);

To make such a "mock comment", on the line that it will point to ?

I saw this first in std.loader: Didn't like it then, don't now ;-)

{
	const int platform_not_discriminated = 0;

	static assert(platform_not_discriminated);
}

Might as well make it into a real comment in the code then:

	assert(0); // no return value


I *think* that assert should take a boolean and a string,
but I don't think it will ever be anything but an integer.

Oh well, if it was good enough for C - why improve it... :-P
--anders
Dec 05 2005
prev sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Lionello Lunesu wrote:

 What would be handy though is the expression appearing in the assert error 
 message. Then you could write "int no_return_value; 
 assert(no_return_value);" and the printed message would contain 
 "no_return_value" as a hint.
 
 L. 


It would indeed be handy, as one could even make it a bit more legible like so:

assert(some_boolean_expression && "this happened because...");

Then the executable would hopefully display the whole expression, from where the
reason for the failure can be read. Of course, if it displays only the failed
part (some_boolean_expression), this doesn't work. :-)
Dec 05 2005
prev sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Anders F Björklund wrote:

 Tiago Gasiba wrote:
 

 Error: AssertError Failure test.d(8)

 Anyonw know why? Thanks! ;-)



 You've defined main() to return an int, but you never return anything.
 Instead of a compiler error, D makes a return-value-less function a
 runtime
 error.  More than once I've wished that the error message would be a
 little
 more specific..





 I agree! Something like "ERROR: no return value" would be much nicer!


 
 
 The compiler just inserts an "assert(0);" line,
 and assert doesn't allow for any such messages...
 e.g. assert(false,"no return at end of function");
 
 func.c(689):
     if (global.params.warnings)
     {    printf("warning - ");
     error("no return at end of function");
     }
 
     if (global.params.useAssert &&
     !global.params.useInline)
     {   /* Add an assert(0); where the missing return
      * should be.
      */
     e = new AssertExp(endloc, new IntegerExp(0, 0, Type::tint32));
     }
     else
     e = new HaltExp(endloc);
 
 Side note: in the above code you can see that if
 you use -inline, then you'll get a "halt" instead!
 Same if you use -release, which disables all asserts.
 
 
 
 This is an oft-requested D feature, that
 assert() is allowed to take messages too.
 
 You can do this in Java, for instance:
 http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
 
 But so far it has been rejected, for D...
 
 
 I think it's similar to "Access Violation",
 which isn't guarded especially for either.
 
 In Java, you would get a NullPointerException
 with the stack trace of the callers (catchable).
 
 In D, it's time to bring out the debugger...


I would very much prefer

*(cast(byte *)0)=0;

over

assert(0);

This would give a segmentation fault that the debugger would be able to 
catch and publish together with context (current stack). Even worse are 
runtime array index out of bounds error without even line number 
information...

/Oskar
Dec 05 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Oskar Linde wrote:


 I would very much prefer
 
 *(cast(byte *)0)=0;
 
 over
 
 assert(0);
 
 This would give a segmentation fault that the debugger would be able to 
 catch and publish together with context (current stack). Even worse are 
 runtime array index out of bounds error without even line number 
 information...


-release should give you a "halt"/crash instead -
but you can also redefine your "_d_assert", from:

extern (C) static void _d_assert(char[] filename, uint line)
{
     //printf("_d_assert(%s, %d)\n", cast(char *)filename, line);
     AssertError a = new AssertError(filename, line);
     //printf("assertion %p created\n", a);
     throw a;
}

 From http://www.digitalmars.com/techtips/unittests.html

--anders
Dec 05 2005
parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Anders F Björklund wrote:

 Oskar Linde wrote:
 

 I would very much prefer

 *(cast(byte *)0)=0;

 over

 assert(0);

 This would give a segmentation fault that the debugger would be able 
 to catch and publish together with context (current stack). Even worse 
 are runtime array index out of bounds error without even line number 
 information...


 
 
 -release should give you a "halt"/crash instead -


So I should use -release to debug? ;)


 but you can also redefine your "_d_assert", from:
 extern (C) static void _d_assert(char[] filename, uint line)
 {
     //printf("_d_assert(%s, %d)\n", cast(char *)filename, line);
     AssertError a = new AssertError(filename, line);
     //printf("assertion %p created\n", a);
     throw a;
 }
 
  From http://www.digitalmars.com/techtips/unittests.html


That's useful, thanks!

/Oskar
Dec 05 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
Oskar Linde wrote:>


 I would very much prefer
 
 *(cast(byte *)0)=0;
 
 over
 
 assert(0);
 
 This would give a segmentation fault that the debugger would be able to 
 catch and publish together with context (current stack). Even worse are 
 runtime array index out of bounds error without even line number 
 information...


One of the first things I did in Ares was to make the assert handler 
overridable, for this exact reason:

void myHandler( char[] file, uint line )
{
     *(cast(byte *)0)=0;
}

// override handler
setAssertHandler( &myHandler );
...
// end override
setAssertHandler( null );


Sean
Dec 05 2005