¿Por qué necesito usar break?

Question

Me preguntaba por qué C# me exige utilizar break en una declaración switch, aunque una semántica fallida por definición no está permitida. por lo tanto, el compilador podría generar el break al final de cada case -block y guardarme la molestia.

Sin embargo, hay un escenario (que ya ha sido discutido en este sitio) que podría llegar a esa podría ser la razón para el uso explícito de break:

switch (foo) { 
    case 0: 
    case 1: 
     bar(); 
     break; 
    default: 
     break; 
} 

En este caso, el método bar() se llama si foo tiene el valor 0 o 1.

Esta opción se rompería en el verdadero sentido de la palabra si el compilador generara break enunciados por sí mismo. ¿Es este el motivo por el cual el descanso es obligatorio o hay otras buenas razones?

Answer 1

Sospecho que la razón por la que C# requiere que el desarrollador coloque un break o una instrucción de terminal al final de cada caso es para mayor claridad.

Evita que los recién llegados al lenguaje asuman que el interruptor() en C# se comporta como el interruptor en C o C++ donde ocurre el comportamiento fallido. Solo en los casos de cajas vacías adyacentes que se producen se producen en C#, lo cual es relativamente obvio.

EDITAR: En realidad, en C# Fallthrough siempre es ilegal. Lo que es legal, sin embargo, es tener un solo caso asociado con dos o más etiquetas. Eric Lippert writes at length about this comportamiento and how it differs from C/C++ switch statements.

Le puede interesar leer this article en el blog de Eric Lipperts.

Answer 2

Mi comprensión del asunto es que se incluyó para que coincida con la sintaxis de C++.

Answer 3

Al hacer pausa opcional, se abre la puerta a los errores de la siguiente manera:

switch (thing_result) 
{ 
    case GOOD_THING: 
     IssueReward(); 
     // UH-OH, missing break! 
    case BAD_THING: 
     IssuePunishment(); 
     break; 
} 

Los diseñadores del lenguaje C# han tratado de ayudar a los programadores a evitar errores en los idiomas en los que había antes de él, en general, al obligar al programador ser más explícito (por ejemplo, uso explícito de la palabra clave 'anular' o 'nueva' para implementar o sombrear miembros virtuales).

Answer 4

Si usted no necesitaría para anexar un descanso, hay un problema

switch (number) 
{ 
    case 0: 
    case 1: 
     DoSomething(); 
} 

¿Qué ocurre si el número == 0? ¿Es esto un caso vacío que no hace nada o se ejecutará DoSomething()?

Answer 5

La pregunta presupone una falsedad y, por lo tanto, no se puede responder. El idioma NO requiere un descanso al final de una sección de interruptor. El lenguaje requiere que la lista de instrucciones de una sección de conmutadores debe tener un punto final inalcanzable. "break" es solo la declaración más comúnmente utilizada que tiene esta propiedad. Es perfectamente legal finalizar una sección de cambio con "return", "goto case 2;", "throw new Exception()"; o "while (true) {}" (o en algunos casos, continúe, aunque eso suele ser una mala idea)

El motivo por el que necesitamos una lista de instrucciones con un punto final inalcanzable es aplicar la regla "no fall through" .

Si su pregunta se expresa mejor como "¿por qué el compilador no repara automáticamente mi error cuando no puedo generar una sección de conmutación con una lista de instrucciones con un punto final inalcanzable al insertar una declaración de interrupción en mi nombre?" , entonces la respuesta es que C# no es una "suposición acerca de lo que el desarrollador probablemente quiso decir y se entretuvo" tipo de lenguaje. Algunos lenguajes son - JScript, por ejemplo - pero C# no lo es.

Creemos que los programadores de C# que cometen errores quieren que se les informe acerca de esos errores para que puedan corregirlos de manera intencional y deliberada, y que esto es algo bueno. Nuestros clientes nos dicen que no quieren que el compilador adivine qué significan y esperan lo mejor. Es por eso que C# tampoco adivina dónde quería colocar el punto y coma faltante, como hace JScript, o falla silenciosamente cuando intenta modificar una variable de solo lectura, como hace JScript, y así sucesivamente.