www.digitalmars.com         C & C++   DMDScript  

D - Possible bug with switch

reply sls1j hotmail.com writes:
An error that kills my program occurs when a value is passed into a switch
statement that doesn't have a matching case.

The following code reproduces the error I'm seeing:

int main()
{
switch( 10 ){
case 1:
break;
case 2:
break;
}

return 0;
}

Thanks,

  Brian Dickey
Apr 21 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
sls1j hotmail.com wrote:

An error that kills my program occurs when a value is passed into a switch
statement that doesn't have a matching case.

The following code reproduces the error I'm seeing:

int main()
{
switch( 10 ){
case 1:
break;
case 2:
break;
}

return 0;
}

Thanks,

  Brian Dickey
  

default: break; ie: int main() { switch( 10 ){ case 1: break; case 2: break; default: break; } return 0; } -- -Anderson: http://badmama.com.au/~anderson/
Apr 21 2004
prev sibling next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Ahh, the classic case of the missing "default:", uhhh, case ...

If you don't explicitly provide a "default:" case for switches, D will
insert one for you which throws an exception. This is to catch a very common
type of error, such as the one you just found ...

There have been many debates over whether this is good or bad behavior on
the compiler's part;

- Kris


<sls1j hotmail.com> wrote in message news:c6707o$2oc5$1 digitaldaemon.com...
 An error that kills my program occurs when a value is passed into a switch
 statement that doesn't have a matching case.

 The following code reproduces the error I'm seeing:

 int main()
 {
 switch( 10 ){
 case 1:
 break;
 case 2:
 break;
 }

 return 0;
 }

 Thanks,

   Brian Dickey

Apr 21 2004
parent reply James Widman <james jwidman.com> writes:
In article <c670gq$2our$1 digitaldaemon.com>, 
 There have been many debates over whether this is good or bad behavior on
 the compiler's part;

Well, it does seem consistent with the language's design philosophy that the sooner you learn about a bug (or potential bug), the better. Much more often than not, leaving out "default:" is unintentional, and it certainly can't hurt to add it, even what immediately follows doesn't really do anything. Erm...hope this doesn't start a flame war. :-)
Apr 21 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
James Widman wrote:
 In article <c670gq$2our$1 digitaldaemon.com>, 
 
There have been many debates over whether this is good or bad behavior on
the compiler's part;

Well, it does seem consistent with the language's design philosophy that the sooner you learn about a bug (or potential bug), the better. Much more often than not, leaving out "default:" is unintentional, and it certainly can't hurt to add it, even what immediately follows doesn't really do anything. Erm...hope this doesn't start a flame war. :-)

No flame war from me, but I'd prefer a compile-time "lack of default" error to the present run-time error for an unmatched case. (I was one of the unhappy participants the last time we had a big discussion on this, and I'm still not satisfied.) But I'm a fan of D whether I get my way on this or not. :) -- Justin http://jcc_7.tripod.com/d/
Apr 21 2004
next sibling parent reply "Unknown W. Brackets" <unknown at.simplemachines.dot.org> writes:
J C Calvarese wrote:

 No flame war from me, but I'd prefer a compile-time "lack of default" 
 error to the present run-time error for an unmatched case. (I was one of 
 the unhappy participants the last time we had a big discussion on this, 
 and I'm still not satisfied.)

But what about when you don't need a default, because it's only going to be either 0 or 1? *Forcing* a default is not, in my opinion, something I would prefer my compiler to do. Maybe it could be an option. Personally, I think a runtime error fits just fine because you can't know if it will be outside or not until it actually runs. Perhaps it could be a warning though? -[Unknown]
Apr 21 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Unknown W. Brackets wrote:

 But what about when you don't need a default, because it's only going 
 to be either 0 or 1?  *Forcing* a default is not, in my opinion, 
 something I would prefer my compiler to do.  Maybe it could be an option.

 Personally, I think a runtime error fits just fine because you can't 
 know if it will be outside or not until it actually runs.

 Perhaps it could be a warning though?

 -[Unknown]

Day-shar-voo (how do you spell it?). Anyway the matrix must be changing something.... -- -Anderson: http://badmama.com.au/~anderson/
Apr 21 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
deja vu (+ some accents)

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c677g8$1q1$3 digitaldaemon.com...
 Unknown W. Brackets wrote:

 But what about when you don't need a default, because it's only going
 to be either 0 or 1?  *Forcing* a default is not, in my opinion,
 something I would prefer my compiler to do.  Maybe it could be an option.

 Personally, I think a runtime error fits just fine because you can't
 know if it will be outside or not until it actually runs.

 Perhaps it could be a warning though?

 -[Unknown]

Day-shar-voo (how do you spell it?). Anyway the matrix must be changing something.... -- -Anderson: http://badmama.com.au/~anderson/

Apr 21 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Unknown W. Brackets" <unknown at.simplemachines.dot.org> wrote in message
news:c6774l$op$3 digitaldaemon.com...
 J C Calvarese wrote:

 No flame war from me, but I'd prefer a compile-time "lack of default"
 error to the present run-time error for an unmatched case. (I was one of
 the unhappy participants the last time we had a big discussion on this,
 and I'm still not satisfied.)

But what about when you don't need a default, because it's only going to be either 0 or 1? *Forcing* a default is not, in my opinion, something I would prefer my compiler to do. Maybe it could be an option.

We don't do options in D. What's so hard about adding one in? Maintenance is the vastly dominant activity in software engineering, so why do you care about the initial "cost" in your time, if you're going to save far more in the future?
 Personally, I think a runtime error fits just fine because you can't
 know if it will be outside or not until it actually runs.

That's a furphy. What's it being "outside or not" got to do with whether or not you write appropriate code?
 Perhaps it could be a warning though?

We don't do warnings in D.
Apr 21 2004
parent reply "Unknown W. Brackets" <unknown at.simplemachines.dot.org> writes:
Matthew wrote:

 That's a furphy. What's it being "outside or not" got to do with whether or not
 you write appropriate code?

I solve that problem by generally avoiding switches when there are small cases, and not using them if I don't know exactly what the variable could be. But having to add a default: to a switch with two items just seems... so very trivial to me. It also presents a barrier to people learning D, because this is not something you expect with *general* C syntax imho. -[Unknown]
Apr 21 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Unknown W. Brackets" <unknown at.simplemachines.dot.org> wrote in message
news:c678e1$3ba$2 digitaldaemon.com...
 Matthew wrote:

 That's a furphy. What's it being "outside or not" got to do with whether or


 you write appropriate code?

I solve that problem by generally avoiding switches when there are small cases, and not using them if I don't know exactly what the variable could be. But having to add a default: to a switch with two items just seems... so very trivial to me. It also presents a barrier to people learning D, because this is not something you expect with *general* C syntax imho.

If you've only got two cases, why not use if / ?: ? Anyway, whether or not it is a barrier to newbies is, again, a furphy. It is far worse to have surprising and unpredictable runtime behaviour than to give a specious usability to the odd newcomer to the language. As soon as they get experience they'll learn to hate the silent default exception. ("They will if they've any sense, anyway", spake the Dr contentiously <g>)
Apr 21 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Darn; I really didn't mean to stir this one up again :-{

Since we're here though, I'll dip my oar in the water: if someone can come
up with a way where the compiler would happily accept the quick porting of
C-like code *without* an explicit "default:" then I think the compile-time
versus runtime debate would end with the compile-time error winning out. In
other words, I imagine there's a backward compatibility factor involved
here. IMHO, the compiler currently provides backward compatibility via the
runtime approach instead.

One way to resolve this would be to provide a (*gulp*), another compiler
switch ...

- Kris

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c678i6$4dg$1 digitaldaemon.com...
 "Unknown W. Brackets" <unknown at.simplemachines.dot.org> wrote in message
 news:c678e1$3ba$2 digitaldaemon.com...
 Matthew wrote:

 That's a furphy. What's it being "outside or not" got to do with



 not
 you write appropriate code?

I solve that problem by generally avoiding switches when there are small cases, and not using them if I don't know exactly what the variable could be. But having to add a default: to a switch with two items just seems... so very trivial to me. It also presents a barrier to people learning D, because this is not something you expect with *general* C syntax imho.

If you've only got two cases, why not use if / ?: ? Anyway, whether or not it is a barrier to newbies is, again, a furphy. It

 worse to have surprising and unpredictable runtime behaviour than to give

 specious usability to the odd newcomer to the language. As soon as they

 experience they'll learn to hate the silent default exception. ("They will

 they've any sense, anyway", spake the Dr contentiously <g>)

Apr 21 2004
next sibling parent Juan C <Juan_member pathlink.com> writes:
Once again I must state my opinion that if D is to be "better" than C, it can
not be centered around "easy porting" and backward compatibility.

up with a way where the compiler would happily accept the quick porting of
C-like code *without* an explicit "default:" then I think the compile-time

Apr 21 2004
prev sibling parent Juan C <Juan_member pathlink.com> writes:
And such a thing should be caught by something like LINT before it ever gets to
the compiler anyway.

But then, it is my opinion that there is too much other LINT-like functionality
bloating the compiler as well.
Apr 21 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 21 Apr 2004 20:27:02 -0500, J C Calvarese wrote:

 James Widman wrote:
 In article <c670gq$2our$1 digitaldaemon.com>, 
 
There have been many debates over whether this is good or bad behavior on
the compiler's part;

Well, it does seem consistent with the language's design philosophy that the sooner you learn about a bug (or potential bug), the better. Much more often than not, leaving out "default:" is unintentional, and it certainly can't hurt to add it, even what immediately follows doesn't really do anything. Erm...hope this doesn't start a flame war. :-)

No flame war from me, but I'd prefer a compile-time "lack of default" error to the present run-time error for an unmatched case. (I was one of the unhappy participants the last time we had a big discussion on this, and I'm still not satisfied.)

Ok, so its a matter of timing (and thus who is told of the situation). Whether the situation is raised at compile-time or at run-time. Obviously the compiler already knows of it as it has to insert the exception throwing code, so I guess the earliest point is at compile-time. I guess this would be better because then the developer finds out about it before the customer using their application.
 But I'm a fan of D whether I get my way on this or not. :)

Me too. -- Derek 22/Apr/04 11:39:39 AM
Apr 21 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Derek Parnell wrote:

 Ok, so its a matter of timing (and thus who is told of the situation).

Whether the situation is raised at compile-time or at run-time. Obviously
the compiler already knows of it as it has to insert the exception throwing
code, so I guess the earliest point is at compile-time. I guess this would
be better because then the developer finds out about it before the customer
using their application.
  

just does this automaticly for him. I've a feeling we're going to hear all same 125 different points of view yet again :( Parhaps someone should summarise what was said last time. *Me* oh no, I'm no good at that kinda thing. Dam it, I just answered this thread. -- -Anderson: http://badmama.com.au/~anderson/
Apr 21 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 In article <c670gq$2our$1 digitaldaemon.com>,
 There have been many debates over whether this is good or bad behavior on
 the compiler's part;

Well, it does seem consistent with the language's design philosophy that the sooner you learn about a bug (or potential bug), the better.

Wrong. It is entirely *in*consistent with that approach: the earliest you can find out about the potential bug is at compile-time. With the current implementation, you might not find out for years!
 Much more often than not, leaving out "default:" is unintentional, and
 it certainly can't hurt to add it, even what immediately follows doesn't
 really do anything.

 Erm...hope this doesn't start a flame war. :-)

It will. (Has.) But it's just a rekindling of an existing one.
Apr 21 2004
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
James Widman wrote:

<snip>
 Well, it does seem consistent with the language's design philosophy that 
 the sooner you learn about a bug (or potential bug), the better.

While inconsistent with another of the language's design philosophies, namely that code that looks like C should act like C. OTOH, the other thing about switch (default fall-through) is keeping with the second philosophy while dodging the first. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Apr 22 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"James Widman" <james jwidman.com> wrote in message
news:james-5E8BAF.20504221042004 digitalmars.com...
 Erm...hope this doesn't start a flame war. :-)

LOL. This is probably the most debated topic in this newsgroup!
Apr 26 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c6jnbk$13o0$2 digitaldaemon.com...
 "James Widman" <james jwidman.com> wrote in message
 news:james-5E8BAF.20504221042004 digitalmars.com...
 Erm...hope this doesn't start a flame war. :-)

LOL. This is probably the most debated topic in this newsgroup!

And the most glaring of D's hypocrisies (given that it wants to make the life of programmers simpler, that is). Must rush. I need a fire extinguisher ...
Apr 26 2004
prev sibling parent Stephan Wienczny <wienczny web.de> writes:
sls1j hotmail.com wrote:

 An error that kills my program occurs when a value is passed into a switch
 statement that doesn't have a matching case.
 
 The following code reproduces the error I'm seeing:
 
 int main()
 {
 switch( 10 ){
 case 1:
 break;
 case 2:
 break;
 }
 
 return 0;
 }
 
 Thanks,
 
   Brian Dickey

Your are absolutely correct. *g* This code throws an Error exception. To avoid this add an default: case to the switch statement.
Apr 21 2004