¿Cuáles son algunas formas mejores de evitar el do-while (0); piratear en C ++?

Cuando el flujo de código es así:

if(check())
{
  ...
  ...
  if(check())
  {
    ...
    ...
    if(check())
    {
      ...
      ...
    }
  }
}

En general, he visto que esto funciona para evitar el flujo de código desordenado anterior:

do {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

¿Cuáles son algunas formas mejores de evitar esta solución / pirateo para que se convierta en un código de nivel superior (nivel industrial)?

¡Cualquier sugerencia que esté lista para usar es bienvenida!

Se considera una práctica aceptable aislar estas decisiones en una función y usar returns en lugar de breaks. Si bien todas estas verificaciones corresponden al mismo nivel de abstracción que la función, es un enfoque bastante lógico.

Por ejemplo:

void foo(...)
{
   if (!condition)
   {
      return;
   }
   ...
   if (!other condition)
   {
      return;
   }
   ...
   if (!another condition)
   {
      return;
   }
   ... 
   if (!yet another condition)
   {
      return;
   }
   ...
   // Some unconditional stuff       
}

Hay momentos en que usar gotoes realmente la respuesta CORRECTA, al menos para aquellos que no se crían en la creencia religiosa de que " gotonunca puede ser la respuesta, sin importar cuál sea la pregunta", y este es uno de esos casos.

Este código está usando el truco do { ... } while(0);con el único propósito de disfrazarse de a gotocomo a break. Si vas a usar goto, entonces sé abierto al respecto. No tiene sentido hacer que el código sea MÁS DURO de leer.

Una situación particular es cuando tienes mucho código con condiciones bastante complejas:

void func()
{
   setup of lots of stuff
   ...
   if (condition)
   {
      ... 
      ...
      if (!other condition)
      {
          ...
          if (another condition)
          {
              ... 
              if (yet another condition)
              {
                  ...
                  if (...)
                     ... 
              }
          }
      }
  .... 

  }
  finish up. 
}

En realidad, puede aclarar que el código es correcto al no tener una lógica tan compleja.

void func()
{
   setup of lots of stuff
   ...
   if (!condition)
   {
      goto finish;
   }
   ... 
   ...
   if (other condition)
   {
      goto finish;
   }
   ...
   if (!another condition)
   {
      goto finish;
   }
   ... 
   if (!yet another condition)
   {
      goto finish;
   }
   ... 
   .... 
   if (...)
         ...    // No need to use goto here. 
 finish:
   finish up. 
}

Editar: Para aclarar, de ninguna manera propongo el uso de gotocomo una solución general. Pero hay casos en que gotoes una mejor solución que otras soluciones.

Imagine, por ejemplo, que estamos recopilando algunos datos, y las diferentes condiciones que se están probando son una especie de "este es el final de los datos que se recopilan", que depende de algún tipo de marcadores de "continuar / finalizar" que varían según el lugar Estás en el flujo de datos.

Ahora, cuando hayamos terminado, debemos guardar los datos en un archivo.

Y sí, a menudo hay otras soluciones que pueden proporcionar una solución razonable, pero no siempre.

Puede usar un patrón de continuación simple con una boolvariable:

bool goOn;
if ((goOn = check0())) {
    ...
}
if (goOn && (goOn = check1())) {
    ...
}
if (goOn && (goOn = check2())) {
    ...
}
if (goOn && (goOn = check3())) {
    ...
}

Esta cadena de ejecución se detendrá tan pronto como checkNregrese a false. No se realizarán más check...()llamadas debido al cortocircuito del &&operador. Por otra parte, los compiladores de optimización son lo suficientemente inteligente como para reconocer que el establecimiento goOnde falseuna calle de sentido único, e inserte el faltante goto endpara usted. Como resultado, el rendimiento del código anterior sería idéntico al de un do/ while(0), solo sin un doloroso golpe a su legibilidad.

1. Intente extraer el código en una función separada (o quizás más de una). Luego regrese de la función si la verificación falla.

2. Si está demasiado unido al código circundante para hacer eso, y no puede encontrar una manera de reducir el acoplamiento, mire el código después de este bloque. Presumiblemente, limpia algunos recursos utilizados por la función. Intente administrar estos recursos utilizando un objeto RAII ; luego reemplaza cada poco fiable breakcon return(o throw, si eso es más apropiado) y deja que el destructor del objeto te limpie.

3. Si el flujo del programa es (necesariamente) tan escabroso que realmente necesitas un goto, entonces úsalo en lugar de darle un disfraz extraño.

4. Si tiene reglas de codificación que lo prohíben ciegamente gotoy realmente no puede simplificar el flujo del programa, entonces probablemente tendrá que disfrazarlo con su dotruco.

TLDR : RAII , código transaccional (solo establece resultados o devuelve cosas cuando ya está calculado) y excepciones.

Respuesta larga:

En C , la mejor práctica para este tipo de código es agregar una etiqueta EXIT / CLEANUP / other en el código, donde se realiza la limpieza de los recursos locales y se devuelve un código de error (si corresponde). Esta es la mejor práctica porque divide el código naturalmente en la inicialización, el cálculo, el compromiso y el retorno:

error_code_type c_to_refactor(result_type *r)
{
    error_code_type result = error_ok; //error_code_type/error_ok defd. elsewhere
    some_resource r1, r2; // , ...;
    if(error_ok != (result = computation1(&r1))) // Allocates local resources
        goto cleanup;
    if(error_ok != (result = computation2(&r2))) // Allocates local resources
        goto cleanup;
    // ...

    // Commit code: all operations succeeded
    *r = computed_value_n;
cleanup:
    free_resource1(r1);
    free_resource2(r2);
    return result;
}

En C, en la mayoría de bases de código, el if(error_ok != ...y gotocódigo está generalmente oculta detrás de unas macros convenientes ( RET(computation_result), ENSURE_SUCCESS(computation_result, return_code), etc.).

C ++ ofrece herramientas adicionales sobre C :

• La funcionalidad del bloque de limpieza se puede implementar como RAII, lo que significa que ya no necesita el cleanupbloque completo y permite que el código del cliente agregue declaraciones de devolución anticipadas.

• Lanzas cuando no puedes continuar, transformando todo if(error_ok != ...en llamadas directas.

Código C ++ equivalente:

result_type cpp_code()
{
    raii_resource1 r1 = computation1();
    raii_resource2 r2 = computation2();
    // ...
    return computed_value_n;
}

Esta es la mejor práctica porque:

• Es explícito (es decir, si bien el manejo de errores no es explícito, el flujo principal del algoritmo sí lo es)

• Es sencillo escribir código de cliente

• Es minima

• Es simple

• No tiene construcciones de código repetitivo

• No usa macros

• No usa do { ... } while(0)construcciones raras

• Es reutilizable con un esfuerzo mínimo (es decir, si quiero copiar la llamada a computation2();una función diferente, no tengo que asegurarme de agregar un do { ... } while(0)código nuevo, ni #defineuna macro de contenedor Goto y una etiqueta de limpieza, ni Algo más).

Estoy agregando una respuesta en aras de la integridad. Varias otras respuestas señalaron que el bloque de condición grande podría dividirse en una función separada. Pero como también se señaló varias veces, este enfoque separa el código condicional del contexto original. Esta es una razón por la que se agregaron lambdas al lenguaje en C ++ 11. Otros sugirieron el uso de lambdas, pero no se proporcionó una muestra explícita. He puesto uno en esta respuesta. Lo que me sorprende es que se siente muy similar al do { } while(0)enfoque en muchos sentidos, y tal vez eso significa que sigue siendo un gotodisfraz ...

earlier operations
...
[&]()->void {

    if (!check()) return;
    ...
    ...
    if (!check()) return;
    ...
    ...
    if (!check()) return;
    ...
    ...
}();
later operations

Ciertamente, no la respuesta, sino una respuesta (en aras de la integridad)

En vez de :

do {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

Podrías escribir:

switch (0) {
case 0:
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

Esto sigue siendo un goto disfrazado, pero al menos ya no es un bucle. Lo que significa que no tendrá que verificar con mucho cuidado que no haya algunos que continúen ocultos en algún lugar del bloque.

La construcción también es lo suficientemente simple como para que pueda esperar que el compilador la optimice.

Como lo sugiere @jamesdlin, incluso puedes ocultar eso detrás de una macro como

#define BLOC switch(0) case 0:

Y úsalo como

BLOC {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

Esto es posible porque la sintaxis del lenguaje C espera una declaración después de un cambio, no un bloque entre corchetes y puede poner una etiqueta de caso antes de esa declaración. Hasta ahora no veía el punto de permitir eso, pero en este caso particular es útil ocultar el interruptor detrás de una buena macro.

Recomendaría un enfoque similar a la respuesta de Mats menos lo innecesario goto. Solo ponga la lógica condicional en la función. Cualquier código que siempre se ejecute debe ir antes o después de invocar la función en la persona que llama:

void main()
{
    //do stuff always
    func();
    //do other stuff always
}

void func()
{
    if (!condition)
        return;
    ...
    if (!other condition)
        return;
    ...
    if (!another condition)
        return;
    ... 
    if (!yet another condition)
        return;
    ...
}

El flujo de código en sí mismo ya es un olor a código que sucede mucho en la función. Si no hay una solución directa para eso (la función es una función de verificación general), entonces usar RAII para que pueda regresar en lugar de saltar a la sección final de la función podría ser mejor.

Si no necesita introducir variables locales durante la ejecución, a menudo puede aplanar esto:

if (check()) {
  doStuff();
}  
if (stillOk()) {
  doMoreStuff();
}
if (amIStillReallyOk()) {
  doEvenMore();
}

// edit 
doThingsAtEndAndReportErrorStatus()

Similar a la respuesta de dasblinkenlight, pero evita la asignación dentro de la ifque podría ser "reparada" por un revisor de código:

bool goOn = check0();
if (goOn) {
    ...
    goOn = check1();
}
if (goOn) {
    ...
    goOn = check2();
}
if (goOn) {
    ...
}

...

Utilizo este patrón cuando los resultados de un paso deben verificarse antes del siguiente paso, lo que difiere de una situación en la que todas las comprobaciones podrían realizarse por adelantado con un if( check1() && check2()...patrón de tipo grande .

Use excepciones. Su código se verá mucho más limpio (y se crearon excepciones exactamente para manejar errores en el flujo de ejecución de un programa). Para limpiar recursos (descriptores de archivos, conexiones de bases de datos, etc.), lea el artículo ¿Por qué C ++ no proporciona una construcción "finalmente"? .

#include <iostream>
#include <stdexcept>   // For exception, runtime_error, out_of_range

int main () {
    try {
        if (!condition)
            throw std::runtime_error("nope.");
        ...
        if (!other condition)
            throw std::runtime_error("nope again.");
        ...
        if (!another condition)
            throw std::runtime_error("told you.");
        ...
        if (!yet another condition)
            throw std::runtime_error("OK, just forget it...");
    }
    catch (std::runtime_error &e) {
        std::cout << e.what() << std::endl;
    }
    catch (...) {
        std::cout << "Caught an unknown exception\n";
    }
    return 0;
}

Para mi do{...}while(0)esta bien. Si no desea ver el do{...}while(0), puede definir palabras clave alternativas para ellos.

Ejemplo:

SomeUtilities.hpp:

#define BEGIN_TEST do{
#define END_TEST }while(0);

SomeSourceFile.cpp:

BEGIN_TEST
   if(!condition1) break;
   if(!condition2) break;
   if(!condition3) break;
   if(!condition4) break;
   if(!condition5) break;
   
   //processing code here

END_TEST

Creo que el compilador eliminará la while(0)condición innecesaria do{...}while(0)en versión binaria y convertirá los saltos en salto incondicional. Puede verificar su versión en lenguaje ensamblador para estar seguro.

El uso gototambién produce un código más limpio y es sencillo con la lógica de condición y luego salto. Puedes hacer lo siguiente:

{
   if(!condition1) goto end_blahblah;
   if(!condition2) goto end_blahblah;
   if(!condition3) goto end_blahblah;
   if(!condition4) goto end_blahblah;
   if(!condition5) goto end_blahblah;
   
   //processing code here

 }end_blah_blah:;  //use appropriate label here to describe...
                   //  ...the whole code inside the block.
 

Tenga en cuenta que la etiqueta se coloca después del cierre }. Este es el evitar un posible problema en el gotoque accidentalmente se coloca un código en el medio porque no vio la etiqueta. Ahora es como do{...}while(0)sin código de condición.

Para hacer este código más limpio y más comprensible, puede hacer esto:

SomeUtilities.hpp:

#define BEGIN_TEST {
#define END_TEST(_test_label_) }_test_label_:;
#define FAILED(_test_label_) goto _test_label_

SomeSourceFile.cpp:

BEGIN_TEST
   if(!condition1) FAILED(NormalizeData);
   if(!condition2) FAILED(NormalizeData);
   if(!condition3) FAILED(NormalizeData);
   if(!condition4) FAILED(NormalizeData);
   if(!condition5) FAILED(NormalizeData);

END_TEST(NormalizeData)

Con esto, puede hacer bloques anidados y especificar dónde desea salir / saltar.

BEGIN_TEST
   if(!condition1) FAILED(NormalizeData);
   if(!condition2) FAILED(NormalizeData);

   BEGIN_TEST
      if(!conditionAA) FAILED(DecryptBlah);
      if(!conditionBB) FAILED(NormalizeData);   //Jump out to the outmost block
      if(!conditionCC) FAILED(DecryptBlah);
  
      // --We can now decrypt and do other stuffs.

   END_TEST(DecryptBlah)

   if(!condition3) FAILED(NormalizeData);
   if(!condition4) FAILED(NormalizeData);

   // --other code here

   BEGIN_TEST
      if(!conditionA) FAILED(TrimSpaces);
      if(!conditionB) FAILED(TrimSpaces);
      if(!conditionC) FAILED(NormalizeData);   //Jump out to the outmost block
      if(!conditionD) FAILED(TrimSpaces);

      // --We can now trim completely or do other stuffs.

   END_TEST(TrimSpaces)

   // --Other code here...

   if(!condition5) FAILED(NormalizeData);

   //Ok, we got here. We can now process what we need to process.

END_TEST(NormalizeData)

El código de espagueti no es gotoculpa del programador. Todavía puede producir código de espagueti sin usar goto.

Este es un problema bien conocido y bien resuelto desde una perspectiva de programación funcional: quizás la mónada.

En respuesta al comentario que recibí a continuación, he editado mi introducción aquí: puede encontrar todos los detalles sobre la implementación de mónadas C ++ en varios lugares que le permitirán lograr lo que sugiere Rotsor. Toma un tiempo asimilar mónadas, así que en su lugar voy a sugerir aquí un mecanismo rápido tipo mónada de "pobre hombre" para el que no necesita saber nada más que boost :: opcional.

Configure sus pasos de cálculo de la siguiente manera:

boost::optional<EnabledContext> enabled(boost::optional<Context> context);
boost::optional<EnergisedContext> energised(boost::optional<EnabledContext> context);

Obviamente, cada paso computacional puede hacer algo como regresar boost::nonesi el opcional que se le dio está vacío. Así por ejemplo:

struct Context { std::string coordinates_filename; /* ... */ };

struct EnabledContext { int x; int y; int z; /* ... */ };

boost::optional<EnabledContext> enabled(boost::optional<Context> c) {
   if (!c) return boost::none; // this line becomes implicit if going the whole hog with monads
   if (!exists((*c).coordinates_filename)) return boost::none; // return none when any error is encountered.
   EnabledContext ec;
   std::ifstream file_in((*c).coordinates_filename.c_str());
   file_in >> ec.x >> ec.y >> ec.z;
   return boost::optional<EnabledContext>(ec); // All ok. Return non-empty value.
}

Luego encadenarlos juntos:

Context context("planet_surface.txt", ...); // Close over all needed bits and pieces

boost::optional<EnergisedContext> result(energised(enabled(context)));
if (result) { // A single level "if" statement
    // do work on *result
} else {
    // error
}

Lo bueno de esto es que puede escribir pruebas unitarias claramente definidas para cada paso computacional. Además, la invocación se lee como un inglés simple (como suele ser el caso con el estilo funcional).

Si no le importa la inmutabilidad y es más conveniente devolver el mismo objeto cada vez que pueda encontrar alguna variación usando shared_ptr o similar.

¿Qué hay de mover las declaraciones if a una función adicional que produce un resultado numérico o enum?

int ConditionCode (void) {
   if (condition1)
      return 1;
   if (condition2)
      return 2;
   ...
   return 0;
}


void MyFunc (void) {
   switch (ConditionCode ()) {
      case 1:
         ...
         break;

      case 2:
         ...
         break;

      ...

      default:
         ...
         break;
   }
}

Algo como esto tal vez

#define EVER ;;

for(EVER)
{
    if(!check()) break;
}

o use excepciones

try
{
    for(;;)
        if(!check()) throw 1;
}
catch()
{
}

Usando excepciones también puede pasar datos.

No estoy particularmente en la forma de usar breako returnen tal caso. Dado que normalmente cuando nos enfrentamos a una situación así, generalmente es un método relativamente largo.

Si tenemos múltiples puntos de salida, puede causar dificultades cuando queremos saber qué causará que se ejecute cierta lógica: normalmente seguimos subiendo bloques que encierran esa pieza de lógica, y los criterios de esos bloques que nos rodean nos dicen el situación:

Por ejemplo,

if (conditionA) {
    ....
    if (conditionB) {
        ....
        if (conditionC) {
            myLogic();
        }
    }
}

Al observar los bloques que encierran, es fácil descubrir que myLogic()solo suceden cuando conditionA and conditionB and conditionCes cierto.

Se vuelve mucho menos visible cuando hay retornos tempranos:

if (conditionA) {
    ....
    if (!conditionB) {
        return;
    }
    if (!conditionD) {
        return;
    }
    if (conditionC) {
        myLogic();
    }
}

Ya no podemos navegar hacia arriba myLogic(), mirando el bloque adjunto para descubrir la condición.

Hay diferentes soluciones que usé. Aqui esta uno de ellos:

if (conditionA) {
    isA = true;
    ....
}

if (isA && conditionB) {
    isB = true;
    ...
}

if (isB && conditionC) {
    isC = true;
    myLogic();
}

(Por supuesto, es bienvenido usar la misma variable para reemplazar todo isA isB isC).

Tal enfoque al menos le dará al lector de código, que myLogic()se ejecuta cuando isB && conditionC. Se le da al lector una pista de que necesita buscar más a fondo lo que hará que B sea cierto.

typedef bool (*Checker)();

Checker * checkers[]={
 &checker0,&checker1,.....，&checkerN,NULL
};

bool checker1(){
  if(condition){
    .....
    .....
    return true;
  }
  return false;
}

bool checker2(){
  if(condition){
    .....
    .....
    return true;
  }
  return false;
}

......

void doCheck(){
  Checker ** checker = checkers;
  while( *checker && (*checker)())
    checker++;
}

¿Qué hay sobre eso?

Otro patrón útil si necesita diferentes pasos de limpieza dependiendo de dónde esté la falla:

    private ResultCode DoEverything()
    {
        ResultCode processResult = ResultCode.FAILURE;
        if (DoStep1() != ResultCode.SUCCESSFUL)
        {
            Step1FailureCleanup();
        }
        else if (DoStep2() != ResultCode.SUCCESSFUL)
        {
            Step2FailureCleanup();
            processResult = ResultCode.SPECIFIC_FAILURE;
        }
        else if (DoStep3() != ResultCode.SUCCESSFUL)
        {
            Step3FailureCleanup();
        }
        ...
        else
        {
            processResult = ResultCode.SUCCESSFUL;
        }
        return processResult;
    }

No soy un programador de C ++ , así que no escribiré ningún código aquí, pero hasta ahora nadie ha mencionado una solución orientada a objetos. Así que aquí está mi suposición al respecto:

Tener una interfaz genérica que proporcione un método para evaluar una sola condición. Ahora puede usar una lista de implementaciones de esas condiciones en su objeto que contiene el método en cuestión. Usted itera sobre la lista y evalúa cada condición, posiblemente rompiendo temprano si falla una.

Lo bueno es que dicho diseño se adhiere muy bien al principio abierto / cerrado , porque puede agregar fácilmente nuevas condiciones durante la inicialización del objeto que contiene el método en cuestión. Incluso puede agregar un segundo método a la interfaz con el método para la evaluación de la condición que devuelve una descripción de la condición. Esto se puede utilizar para sistemas de autodocumentación.

La desventaja, sin embargo, es que hay un poco más de sobrecarga involucrada debido al uso de más objetos y la iteración sobre la lista.

Así es como lo hago.

void func() {
  if (!check()) return;
  ...
  ...

  if (!check()) return;
  ...
  ...

  if (!check()) return;
  ...
  ...
}

Primero, un breve ejemplo para mostrar por qué gotono es una buena solución para C ++:

struct Bar {
    Bar();
};

extern bool check();

void foo()
{
    if (!check())
       goto out;

    Bar x;

    out:
}

Intente compilar esto en un archivo de objeto y vea qué sucede. Luego prueba el equivalente do+ break+while(0) .

Eso fue un aparte. El punto principal sigue.

Esos pequeños fragmentos de código a menudo requieren algún tipo de limpieza en caso de que falle toda la función. Esas limpiezas por lo general quieren que sucedan en el orden opuesto de los trozos mismos, ya que "desenrolla" el cálculo parcialmente terminado.

Una opción para obtener esta semántica es RAII ; ver la respuesta de @ utnapistim. C ++ garantiza que los destructores automáticos se ejecutan en el orden opuesto a los constructores, lo que naturalmente proporciona un "desenrollado".

Pero eso requiere muchas clases de RAII. A veces, una opción más simple es usar la pila:

bool calc1()
{
    if (!check())
        return false;

    // ... Do stuff1 here ...

    if (!calc2()) {
        // ... Undo stuff1 here ...
        return false;
    }

    return true;
}

bool calc2()
{
    if (!check())
        return false;

    // ... Do stuff2 here ...

    if (!calc3()) {
        // ... Undo stuff2 here ...
        return false;
    }

    return true;
}

...y así. Esto es fácil de auditar, ya que coloca el código "deshacer" al lado del código "hacer". La auditoría fácil es buena. También hace que el control de flujo sea muy claro. También es un patrón útil para C.

Puede requerir que las calcfunciones tomen muchos argumentos, pero eso generalmente no es un problema si sus clases / estructuras tienen buena cohesión. (Es decir, las cosas que pertenecen juntas viven en un solo objeto, por lo que estas funciones pueden tomar punteros o referencias a un pequeño número de objetos y aún hacer mucho trabajo útil).

Si el código tiene un bloque largo de sentencias if..else if..else, puede intentar reescribir todo el bloque con la ayuda de Functorso function pointers. Puede que no sea la solución correcta siempre, pero a menudo lo es.

http://www.cprogramming.com/tutorial/functors-function-objects-in-c++.html

Me sorprende la cantidad de respuestas diferentes que se presentan aquí. Pero, finalmente, en el código que tengo que cambiar (es decir, eliminar este do-while(0)truco o algo), hice algo diferente de cualquiera de las respuestas que se mencionan aquí y estoy confundido por qué nadie pensó esto. Esto es lo que hice:

Código inicial:

do {

    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

finishingUpStuff.

Ahora:

finish(params)
{
  ...
  ...
}

if(!check()){
    finish(params);    
    return;
}
...
...
if(!check()){
    finish(params);    
    return;
}
...
...
if(!check()){
    finish(params);    
    return;
}
...
...

¡Entonces, lo que se ha hecho aquí es que las cosas de acabado se han aislado en una función y las cosas se han vuelto tan simples y limpias de repente!

Pensé que valía la pena mencionar esta solución, así que proporcione aquí.

Consolidarlo en una sola ifdeclaración:

if(
    condition
    && other_condition
    && another_condition
    && yet_another_condition
    && ...
) {
        if (final_cond){
            //Do stuff
        } else {
            //Do other stuff
        }
}

Este es el patrón utilizado en lenguajes como Java donde se eliminó la palabra clave goto.

Si usa el mismo controlador de errores para todos los errores, y cada paso devuelve un valor bool que indica éxito:

if(
    DoSomething() &&
    DoSomethingElse() &&
    DoAThirdThing() )
{
    // do good condition action
}
else
{
    // handle error
}

(Similar a la respuesta de tyzoid, pero las condiciones son las acciones, y el && evita que ocurran acciones adicionales después de la primera falla).

¿Por qué no se respondió el método de marcado? Se utiliza desde hace siglos.

//you can use something like this (pseudocode)
long var = 0;
if(condition)  flag a bit in var
if(condition)  flag another bit in var
if(condition)  flag another bit in var
............
if(var == certain number) {
Do the required task
}