View mode: basic / threaded / horizontal-split · Log in · Help
November 28, 2003
Re: switch statement improvement?
> 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!!
November 28, 2003
Re: switch statement improvement?
"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.
November 28, 2003
Re: switch statement improvement?
"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>.
November 28, 2003
Re: switch statement improvement?
"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?

:-)
November 28, 2003
Re: default return Re: switch statement improvement?
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.
>
>
November 28, 2003
Re: switch statement improvement?
"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
November 28, 2003
Re: switch statement improvement?
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
November 28, 2003
Re: switch statement improvement?
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
November 28, 2003
Re: switch statement improvement?
"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.
November 28, 2003
Re: switch statement improvement?
"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.
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home