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)" ?

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.

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

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

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

"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.