Walter wrote:
> But it isn't always an error to write such code. Always diagnosing it as an
> error means that you have to insert superfluous return statements in that
> will never get executed. I've already pointed out why this is undesirable.
> 
>

You mean writing superfluous return statements like this:

int someFunc() {
  throw new NotYetWrittenException();
  return 0; //superfluous?  Methinks so. Never Get executed? Absolutely
}

:)

Scott

"Walter" <newshound@digitalmars.com> skrev i en meddelelse news:cgka7p$4c2$1@digitaldaemon.com...
> Yes, you could always write a comment. The trouble with comments, though,
is
> they are always wrong, out of date, or missing. When examining code, I prefer to rely on the semantics of the language <g>.

Perhaps it would help if we had some construct that told both the fellow-programmer and the compiler, that it is an error if the program flow ever reached that point. assert(0) is traditionally used, but it is only good in debug builds. If we had a specialized construct, it would allow the compiler to perform optimizations on that basis, and we would have a way to make the compiler keep quiet about missing return values.

Regards,
Martin

In article <cgln3i$qqg$1@digitaldaemon.com>, stonecobra says...

Nice one! He he he. Several <g>s and a :)
Don't you just love consistency!
Jill


>Walter wrote:
>> But it isn't always an error to write such code. Always diagnosing it as an error means that you have to insert superfluous return statements in that will never get executed. I've already pointed out why this is undesirable.
>> 
>>
>
>You mean writing superfluous return statements like this:
>
>int someFunc() {
>   throw new NotYetWrittenException();
>   return 0; //superfluous?  Methinks so. Never Get executed? Absolutely
>}
>
>:)
>
>Scott
>

"Martin M. Pedersen" <martin@moeller-pedersen.dk> wrote in message news:cglq6t$sad$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> skrev i en meddelelse news:cgka7p$4c2$1@digitaldaemon.com...
> > Yes, you could always write a comment. The trouble with comments,
though,
> is
> > they are always wrong, out of date, or missing. When examining code, I prefer to rely on the semantics of the language <g>.
>
> Perhaps it would help if we had some construct that told both the fellow-programmer and the compiler, that it is an error if the program
flow
> ever reached that point. assert(0) is traditionally used, but it is only good in debug builds. If we had a specialized construct, it would allow
the
> compiler to perform optimizations on that basis, and we would have a way
to
> make the compiler keep quiet about missing return values.

That could be done, and is what Matthew proposed. But I don't see this as a big enough problem to justify adding a new keyword. Having the exception generated if one does erroneously run off the end is sufficient.