• sls1j hotmail.com (15/15) Apr 21 2004 An error that kills my program occurs when a value is passed into a swit...
• J Anderson (18/34) Apr 21 2004 You need
• Kris (8/23) Apr 21 2004 Ahh, the classic case of the missing "default:", uhhh, case ...
• James Widman (7/9) Apr 21 2004 Well, it does seem consistent with the language's design philosophy that...
• J C Calvarese (9/23) Apr 21 2004 No flame war from me, but I'd prefer a compile-time "lack of default"
• Unknown W. Brackets (8/12) Apr 21 2004 But what about when you don't need a default, because it's only going to...
• J Anderson (5/12) Apr 21 2004 Day-shar-voo (how do you spell it?). Anyway the matrix must be changing...
• Matthew (3/19) Apr 21 2004 deja vu (+ some accents)
• Matthew (9/20) Apr 21 2004 We don't do options in D.
• Unknown W. Brackets (8/10) Apr 21 2004 I solve that problem by generally avoiding switches when there are small...
• Matthew (9/18) Apr 21 2004 not
• Kris (18/39) Apr 21 2004 Darn; I really didn't mean to stir this one up again :-{
• Juan C (2/4) Apr 21 2004
• Juan C (4/4) Apr 21 2004 And such a thing should be caught by something like LINT before it ever ...
• Derek Parnell (11/32) Apr 21 2004 Ok, so its a matter of timing (and thus who is told of the situation).
• J Anderson (10/17) Apr 21 2004 As a design practice, in C++ Walter put the exception in as well, D
• Matthew (4/13) Apr 21 2004 Wrong. It is entirely *in*consistent with that approach: the earliest yo...
• Stewart Gordon (11/13) Apr 22 2004 While inconsistent with another of the language's design philosophies,
• Walter (3/4) Apr 26 2004 LOL. This is probably the most debated topic in this newsgroup!
• Matthew (5/9) Apr 26 2004 And the most glaring of D's hypocrisies (given that it wants to make the...
• Stephan Wienczny (3/23) Apr 21 2004 Your are absolutely correct. *g* This code throws an Error exception. To...

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

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
  

You need

default: break;

ie:

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

return 0;
}


-- 
-Anderson: http://badmama.com.au/~anderson/

"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

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. :-)

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/

"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]

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/

"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/

"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.

"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]

"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


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 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>)

"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



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.

 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>)

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

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.

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

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.
  

As a design practice, in C++ Walter put the exception in as well,  D 
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/

"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.

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.

"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!

"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 ...

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.