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

Exactamundo, my friend.

Exceptions are great for somethings, including actual serious/fatal errors, or when doing stuff like deep-level parsing.

Where they are absolutely not appropriate - and I can't believe this is even a discusson - is a runtime report of a code-time mistake!!

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bq60t4$2gol$1@digitaldaemon.com...
> 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.

You're right that it would be better to do it at compile time, but like array bounds checking, it is impossible to do at compile time.

"Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message news:bq65gu$2n8o$1@digitaldaemon.com...
> > Have to agree here, I rareley ( never ? ) use exceptions , and dont like them being thrown without my knoweldge / consent.
>
> Exactamundo, my friend.
>
> Exceptions are great for somethings, including actual serious/fatal
errors,
> or when doing stuff like deep-level parsing.
>
> Where they are absolutely not appropriate - and I can't believe this is
even
> a discusson - is a runtime report of a code-time mistake!!

There's no way to detect the error at compile time. What it's for is when one has:

#1
    switch (x)
    {
        case 1: ...
        case 2: ...
        case 3: ...
    }

and then one day x has the value 4. In C, there's an implicit default:break; inserted when no default is explicitly supplied. But in my experience coding, debugging my own mistakes, and fixing other peoples' code, the implicit default break is almost always the WRONG thing to happen, and then something unexpected happens as a result (i.e. crash, data corruption, etc.). When I see C code like that, and can ask the author, the intention is that x will always be 1, 2 or 3 and NEVER anything else. That's why he wrote the switch that way. That's ok, but then the maintenance programmer adds a feature where x is 4, updates all the switch statements accordingly, but inevitably misses one in the 100,000 line program he's revising. Even if the original coder INTENDED to make use of the implicit default:break;, it has that distinct odor of a bug, and so I flag it in code reviews. And in my experience, it was never intended.

For years, I've advocated 'defensive programming' in C by making it explicit that the default case can never happen with:

#2
    switch (x)
    {
        case 1: ...
        case 2: ...
        case 3: ...
        default:
            assert(0);
    }

This is the normal practice in my own code. There are 3 situations to deal with, the above one, and:

#3
    switch (x)
    {
        case 1: ...
        case 2: ...
        case 3: ...
        default:
            break;
    }

and:

#4
    switch (x)
    {
        case 1: ...
        case 2: ...
        case 3: ...
        default:
            do something
            break;
    }

What D does is make it easy to ensure that all the bases are covered by generating #2 if a default is not supplied. You're not going to get caught with a random crash from forgetting to deal with a case. The compiler cannot do this at compile time because it has no way of determining all possible values x can take. In that way, it's similar to run time array bounds checking. The only other way of doing this with a hope of robustness is to *require* an explicitly written default statement for every switch. This would certainly be a valid language strategy, but I don't really want to be nagged by the compiler to insert a default:assert(0); when I know darn well that x can never be 4 <g>.

"Walter" <walter@digitalmars.com> wrote in message news:bq6hkq$79q$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message news:bq65gu$2n8o$1@digitaldaemon.com...
> > > Have to agree here, I rareley ( never ? ) use exceptions , and dont
like
> > > them being thrown without my knoweldge / consent.
> >
> > Exactamundo, my friend.
> >
> > Exceptions are great for somethings, including actual serious/fatal
> errors,
> > or when doing stuff like deep-level parsing.
> >
> > Where they are absolutely not appropriate - and I can't believe this is
> even
> > a discusson - is a runtime report of a code-time mistake!!
>
> There's no way to detect the error at compile time. What it's for is when one has:
>
> #1
>     switch (x)
>     {
>         case 1: ...
>         case 2: ...
>         case 3: ...
>     }
>
> and then one day x has the value 4. In C, there's an implicit
default:break;
> inserted when no default is explicitly supplied. But in my experience coding, debugging my own mistakes, and fixing other peoples' code, the implicit default break is almost always the WRONG thing to happen, and
then
> something unexpected happens as a result (i.e. crash, data corruption, etc.). When I see C code like that, and can ask the author, the intention
is
> that x will always be 1, 2 or 3 and NEVER anything else. That's why he
wrote
> the switch that way. That's ok, but then the maintenance programmer adds a feature where x is 4, updates all the switch statements accordingly, but inevitably misses one in the 100,000 line program he's revising. Even if
the
> original coder INTENDED to make use of the implicit default:break;, it has that distinct odor of a bug, and so I flag it in code reviews. And in my experience, it was never intended.
>
> For years, I've advocated 'defensive programming' in C by making it
explicit
> that the default case can never happen with:
>
> #2
>     switch (x)
>     {
>         case 1: ...
>         case 2: ...
>         case 3: ...
>         default:
>             assert(0);
>     }
>
> This is the normal practice in my own code. There are 3 situations to deal with, the above one, and:
>
> #3
>     switch (x)
>     {
>         case 1: ...
>         case 2: ...
>         case 3: ...
>         default:
>             break;
>     }
>
> and:
>
> #4
>     switch (x)
>     {
>         case 1: ...
>         case 2: ...
>         case 3: ...
>         default:
>             do something
>             break;
>     }
>
> What D does is make it easy to ensure that all the bases are covered by generating #2 if a default is not supplied. You're not going to get caught with a random crash from forgetting to deal with a case. The compiler
cannot
> do this at compile time because it has no way of determining all possible values x can take. In that way, it's similar to run time array bounds checking. The only other way of doing this with a hope of robustness is to *require* an explicitly written default statement for every switch. This would certainly be a valid language strategy, but I don't really want to
be
> nagged by the compiler to insert a default:assert(0); when I know darn
well
> that x can never be 4 <g>.

It's smacking me between the eyes that requiring the default is the sensible strategy. Original authoring costs are cheap; maintenance costs are expensive. You're just contradicting the bulk of this erudite argument by your knowingly weak convenience.

Walter, if I can lose my bad habit of using leading underscores, I think you can endure this egregious constraint for the greater D good, no?

:-)

Me too... I think that syntax should be more strict in D than in C/C++, so I agree with Walter's PoW: a piece of code is either acceptable or not i.e. gives error or not (ok, viceversa ;). For this case I think the return should be explicitely given or, at least, to state that any function will return (implicitely) the initialization type value (the variable's default value). Anyway, interesting subject.

BTW in Matlab, the warning is like: Warning: some output arguments never assigned in function xxx.



In article <bq5lir$1v0j$1@digitaldaemon.com>, Matthew Wilson says...
>
>> >>
>> >>     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.
>
>

"Walter" <walter@digitalmars.com> wrote in message news:bq3pkp$24v0$1@digitaldaemon.com...
> > 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.

It is conceivable that due to a HW glitch or Act of God that x actually turns up 0 once every 4 billion runs.  If you can't be 200% sure, I would rather the compiler bitch at me, or automatically insert some code that will never run, bloating my app by a few bytes, than take the chance of having execution fall off the end of my function.

It *is* possible to do this 100% if you require that all return paths are explicitly marked and handled, i.e. reject the above code as erroneous due to potential execution path problems.

The problem with the above function is that it's probably written inside out anyway... maybe it should have been written as this:

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

or this:

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

Sean

In article <bq5g2i$1m63$1@digitaldaemon.com>, Walter says...
>
>
>"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.)

You forget you philosophically object to compiler options, too. I suggest to add it to your paper.

Ciao

In article <bq6kl9$bd6$1@digitaldaemon.com>, Matthew Wilson says...
>
>"Walter" <walter@digitalmars.com> wrote in message news:bq6hkq$79q$1@digitaldaemon.com...
[...]
>>The only other way of doing this with a hope of robustness is to
>> *require* an explicitly written default statement for every switch. This would certainly be a valid language strategy, but I don't really want to
>be
>> nagged by the compiler to insert a default:assert(0); when I know darn
>well
>> that x can never be 4 <g>.
>
>It's smacking me between the eyes that requiring the default is the sensible strategy. Original authoring costs are cheap; maintenance costs are expensive. You're just contradicting the bulk of this erudite argument by your knowingly weak convenience.

I also support requiring default. The laziness is your biggest enemy,
so type those 8 keys on the keyboard and that's all. But I know I'm almost alone
here: people want to save typing, not to produce robust code.

BTW, what about user defined enum? Can the compiler know whether all enum constants are used inside a switch, and signal to the programmer when some are missing and there is not a default?

Ciao

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:bq7gm2$1nqo$1@digitaldaemon.com...
> BTW, what about user defined enum? Can the compiler know whether all enum constants are used inside a switch, and signal to the programmer when some
are
> missing and there is not a default?

Yes, but it would be presumptious for the compiler to assume that all values of an enum are possible.

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:bq7g8g$1n6g$1@digitaldaemon.com...
> In article <bq5g2i$1m63$1@digitaldaemon.com>, Walter says...
> >"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.)
>
> You forget you philosophically object to compiler options, too. I suggest to add it to your paper.

LOL! They're both related, that's for sure.