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

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/

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

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.

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

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/

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]

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/

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

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