• Kris (11/11) Jan 09 2006 If you accidently leave out a return statement, a runtime error occurs w...
• Hasan Aljudy (10/25) Jan 09 2006 I think it is possible. Instead of inserting
• BCS (3/9) Jan 10 2006 This is something I have also wished for in the past. Just a file and li...
• Sean Kelly (15/18) Jan 09 2006 It's technically possible, but it may go against what Walter intends for...
• Garett Bass (2/28) Jan 10 2006
• Jarrett Billingsley (3/6) Jan 11 2006 If you turn on warnings, it tells you.

"Kris" <fu bar.com> writes:

If you accidently leave out a return statement, a runtime error occurs when 
that path is executed. It used to be that the error would be a system-level 
one (a halt instruction, I think?) which gave no useful information 
whatsoever about the original problem.

The recent compiler versions have apparently changed this (or at least 
something better happens without -O) such that an assert error is emitted ~ 
this at least shows the filename and line number. Hoorah! Hoorah! However, 
it would be much more helpful if the assert message said something more than 
"Error: AssertError Failure token(29)"

Is it just not technically possible to emit a message of the form "Missing 
return statement in token.d (29)" ? 

Hasan Aljudy <hasan.aljudy gmail.com> writes:

Kris wrote:
 If you accidently leave out a return statement, a runtime error occurs when 
 that path is executed. It used to be that the error would be a system-level 
 one (a halt instruction, I think?) which gave no useful information 
 whatsoever about the original problem.
 
 The recent compiler versions have apparently changed this (or at least 
 something better happens without -O) such that an assert error is emitted ~ 
 this at least shows the filename and line number. Hoorah! Hoorah! However, 
 it would be much more helpful if the assert message said something more than 
 "Error: AssertError Failure token(29)"
 
 Is it just not technically possible to emit a message of the form "Missing 
 return statement in token.d (29)" ? 
 
 

I think it is possible. Instead of inserting
#assert(false);
the compile would have to insert
#throw new ReturnException("Function " ~ func.magic.name ~ " exited 
without returning anything");

where func.magic.name would be something like the
#this.classinfo.name
except it should return the function name.
I don't know if such a thing exists or not.

BCS <BCS_member pathlink.com> writes:

Hasan Aljudy wrote:
 Kris wrote:
 
 where func.magic.name would be something like the
 #this.classinfo.name
 except it should return the function name.
 I don't know if such a thing exists or not.

This is something I have also wished for in the past. Just a file and line 
number (as a string) would do it

Sean Kelly <sean f4.ca> writes:

Kris wrote:
 
 Is it just not technically possible to emit a message of the form "Missing 
 return statement in token.d (29)" ? 

It's technically possible, but it may go against what Walter intends for 
assertions as he's been somewhat resistant to the suggestion of 
assertion messages in the past.  But I'd love for this to change.  Since 
shipping code does sometimes leave assertions in place, I'd prefer if 
there were some way to display meaningful error messages on termination. 
  It also offers a way to track down the offending line without digging 
through the version control archives.  The change would be relatively 
simple.  Add support for an optional char[] argument in asserts and pass 
this through to the callback function.  Then the code generated for end 
of line messages could be:

assert( 0, "Missing return statement." );

instead of:

assert( 0 );


Sean

Garett Bass <garettbass studiotekne.com> writes:

This seems like something the compiler should check.  I seem to recall my C++
compiler warning me "not all paths return a value", or something similar.

Sean Kelly wrote:
 Kris wrote:
 
 Is it just not technically possible to emit a message of the form 
 "Missing return statement in token.d (29)" ? 

 
 
 It's technically possible, but it may go against what Walter intends for 
 assertions as he's been somewhat resistant to the suggestion of 
 assertion messages in the past.  But I'd love for this to change.  Since 
 shipping code does sometimes leave assertions in place, I'd prefer if 
 there were some way to display meaningful error messages on termination. 
  It also offers a way to track down the offending line without digging 
 through the version control archives.  The change would be relatively 
 simple.  Add support for an optional char[] argument in asserts and pass 
 this through to the callback function.  Then the code generated for end 
 of line messages could be:
 
 assert( 0, "Missing return statement." );
 
 instead of:
 
 assert( 0 );
 
 
 Sean

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Garett Bass" <garettbass studiotekne.com> wrote in message 
news:dq27nv$msk$1 digitaldaemon.com...
 This seems like something the compiler should check.  I seem to recall my 
 C++ compiler warning me "not all paths return a value", or something 
 similar.

If you turn on warnings, it tells you.