"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bq3blg$1fvl$1@digitaldaemon.com...
> Vathix wrote:
> > I do that too, and don't like it much. I do, however, like how an
exception
> > is thrown if the end of a non-void function is reached.
>
> Huh? How can that happen? Doesn't the compiler check at compile time that there is a return statement in each possible path? All C/C++ compilers I know will at least issue a warning in such a case (though it should be an error). DMD doesn't do that?

The problem is it's not possible to do this 100%. Consider the trivial case:

    int foo(int x)
    {
        while (x)
        {
            blahblah
            if (blah blah)
                return 3;
        }
    }

The programmer may know that x is never 0, but the compiler can't figure it out. Hence it stuffs a throw at the end. Sure, it's a contrived example, but I've seen cases of this in real code.

"Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message news:bq2vi2$tqd$1@digitaldaemon.com...
> > A good idea, but this is already addressed in D where the default case,
if
> > not specified, is to throw an exception.
> Wow! That's a *really*, *REALLY* bad idea.
> If one is porting some code which very rarely uses the default case - it's
> largely irrelevant whether that's benign or a bug - it may easily escape
the
> test cases, and "sometime later", in production code, an exception will be thrown which has never been anticipated and therefore never been handled.

If it's never been anticipated and never been handled, then it's a program bug. What the exception does is give a controlled failure of the program, rather than an unpredictable erratic behavior.


> This is about the very best/worst example I could possibly think of in the debate between compile-time and runtime error-handling. Rather than
causing
> me 30 seconds in development time, I am up for an unknown, and potentially huge, cost sometime after deployment. Is D really wanting to be a serious systems language?

A robust system programming language *should* give an exception on an unanticipated, unhandled situation.

Walter wrote:
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
> news:bq3blg$1fvl$1@digitaldaemon.com...
> 
>>Vathix wrote:
>>
>>>I do that too, and don't like it much. I do, however, like how an

> The problem is it's not possible to do this 100%. Consider the trivial case:
> 
>     int foo(int x)
>     {
>         while (x)
>         {
>             blahblah
>             if (blah blah)
>                 return 3;
>         }
>     }
> 
> The programmer may know that x is never 0, but the compiler can't figure it
> out. Hence it stuffs a throw at the end. Sure, it's a contrived example, but
> I've seen cases of this in real code.

VC6 issues a warning in that case:
"warning C4715: 'foo' : not all control paths return a value"

I agree that such a case should be allowed without requiring an explicit return that you know will never be reached. But can't the compiler issue a warning at compile time in addition to the runtime exception.

I quite often write functions that return a boolean that (should) end with "return true;". However, I sometimes simply forget the last return (having just dealt with complicated error-cases the normal case return sometimes slips my mind). I like it if the compiler warns me about that.

Maybe that warning could be made optional with a commandline switch?

Hauke

>> 
>>     int foo(int x)
>>     {
>>         while (x)
>>         {
>>             blahblah
>>             if (blah blah)
>>                 return 3;
>>         }
>>     }
>> 
>> The programmer may know that x is never 0, but the compiler can't figure it out. Hence it stuffs a throw at the end. Sure, it's a contrived example, but I've seen cases of this in real code.
>
>VC6 issues a warning in that case:
>"warning C4715: 'foo' : not all control paths return a value"
>
>I agree that such a case should be allowed without requiring an explicit return that you know will never be reached.

why allow it? this is bad code, at least issue a warning because someone someday will call foo() with a 0

Mark T wrote:
>>>    int foo(int x)
>>>    {
>>>        while (x)
>>>        {
>>>            blahblah
>>>            if (blah blah)
>>>                return 3;
>>>        }
>>>    }
>>>
>>>The programmer may know that x is never 0, but the compiler can't figure it
>>>out. Hence it stuffs a throw at the end. Sure, it's a contrived example, but
>>>I've seen cases of this in real code.
>>
>>VC6 issues a warning in that case:
>>"warning C4715: 'foo' : not all control paths return a value"
>>
>>I agree that such a case should be allowed without requiring an explicit return that you know will never be reached. 
> 
> 
> why allow it? this is bad code, at least issue a warning because someone someday
> will call foo() with a 0

Well, if 0 is an invalid argument, then throwing an exception would be the right thing to do. This might save the programmer the need to do it manually.

Though now that I think about it ... in almost all cases I can imagine one would want the exception to be something like InvalidArgError. If you get UnexpectedEndOfFunction (or whatever is thrown) that sounds like there is a bug in the function, instead of a bug in the calling code.

And these cases should be rare enough that an "unnecessary" return statement wouldn't really amount to much of a hassle.

I also just realized that we will never get Walter to add warnings to the compiler, so I'll switch sides. I'm all for making it an error now ;). It's still much better than having the compiler not complain at all about such a thing...

Hauke

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
> Maybe that warning could be made optional with a commandline switch?

I need to write a short paper on why I philosophically object to warnings! (This issue comes up repeatedly.)

> >>
> >>     int foo(int x)
> >>     {
> >>         while (x)
> >>         {
> >>             blahblah
> >>             if (blah blah)
> >>                 return 3;
> >>         }
> >>     }
> >>
> >> The programmer may know that x is never 0, but the compiler can't
figure it
> >> out. Hence it stuffs a throw at the end. Sure, it's a contrived
example, but
> >> I've seen cases of this in real code.
> >
> >VC6 issues a warning in that case:
> >"warning C4715: 'foo' : not all control paths return a value"
> >
> >I agree that such a case should be allowed without requiring an explicit return that you know will never be reached.
>
> why allow it? this is bad code, at least issue a warning because someone
someday
> will call foo() with a 0

Agreed. It has to be an error.

> > > A good idea, but this is already addressed in D where the default
case,
> if
> > > not specified, is to throw an exception.
> > Wow! That's a *really*, *REALLY* bad idea.
> > If one is porting some code which very rarely uses the default case -
it's
> > largely irrelevant whether that's benign or a bug - it may easily escape
> the
> > test cases, and "sometime later", in production code, an exception will
be
> > thrown which has never been anticipated and therefore never been
handled.
>
> If it's never been anticipated and never been handled, then it's a program bug. What the exception does is give a controlled failure of the program, rather than an unpredictable erratic behavior.

This is just plain wrong. What you're saying is that D must reflect the bugs inherent in code that is ported in from other languages, so kind of admitting defeat, or that D should facilitate, nay encourage, the shit practises of people who have abused weaknesses in other languages.

> > This is about the very best/worst example I could possibly think of in
the
> > debate between compile-time and runtime error-handling. Rather than
> causing
> > me 30 seconds in development time, I am up for an unknown, and
potentially
> > huge, cost sometime after deployment. Is D really wanting to be a
serious
> > systems language?
>
> A robust system programming language *should* give an exception on an unanticipated, unhandled situation.

A robust system programming language should favour compile time error fixes than runtime ones.

Since exceptions are a questionable error-handling mechanism at best (flame me now, you "modern" programmers!!!) you're locking people into having to care about arbitrary bugs, in arbitrary modules (that may be other people's libraries), when this could all be obviated by the compiler doing marginally better than those for languages D that purports to be an improvement over.

Sorry, but, much as I love and respect the very air that you breath Walter ;), this is just utter folly.

Bertie Betterment

Have to agree here, I rareley ( never ? ) use exceptions , and dont like them being thrown without my knoweldge / consent.



C

"Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message news:bq5m7f$2023$1@digitaldaemon.com...
> > > > A good idea, but this is already addressed in D where the default
> case,
> > if
> > > > not specified, is to throw an exception.
> > > Wow! That's a *really*, *REALLY* bad idea.
> > > If one is porting some code which very rarely uses the default case -
> it's
> > > largely irrelevant whether that's benign or a bug - it may easily
escape
> > the
> > > test cases, and "sometime later", in production code, an exception
will
> be
> > > thrown which has never been anticipated and therefore never been
> handled.
> >
> > If it's never been anticipated and never been handled, then it's a
program
> > bug. What the exception does is give a controlled failure of the
program,
> > rather than an unpredictable erratic behavior.
>
> This is just plain wrong. What you're saying is that D must reflect the
bugs
> inherent in code that is ported in from other languages, so kind of admitting defeat, or that D should facilitate, nay encourage, the shit practises of people who have abused weaknesses in other languages.
>
> > > This is about the very best/worst example I could possibly think of in
> the
> > > debate between compile-time and runtime error-handling. Rather than
> > causing
> > > me 30 seconds in development time, I am up for an unknown, and
> potentially
> > > huge, cost sometime after deployment. Is D really wanting to be a
> serious
> > > systems language?
> >
> > A robust system programming language *should* give an exception on an unanticipated, unhandled situation.
>
> A robust system programming language should favour compile time error
fixes
> than runtime ones.
>
> Since exceptions are a questionable error-handling mechanism at best
(flame
> me now, you "modern" programmers!!!) you're locking people into having to care about arbitrary bugs, in arbitrary modules (that may be other
people's
> libraries), when this could all be obviated by the compiler doing
marginally
> better than those for languages D that purports to be an improvement over.
>
> Sorry, but, much as I love and respect the very air that you breath Walter ;), this is just utter folly.
>
> Bertie Betterment
>
>

Walter wrote:
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
> 
>>Maybe that warning could be made optional with a commandline switch?
> 
> 
> I need to write a short paper on why I philosophically object to warnings!
> (This issue comes up repeatedly.)


I know the way you feel about this. Maybe you're right and the necessity for warnings are a sign of a badly designed language.

However - and I don't mean to be trolling here, just speaking my mind - if you refuse to employ one particular kind of workaround for a design flaw then you shouldn't just invent a new workaround, but instead try to find a real solution for the flaw!

This kind of exception is just a kind of warning (actually more like an error) that is issued at runtime, instead of compile time. IMHO that's a step in the wrong direction.

Hauke