Member Avatar for myk45

Hello All!

To check for return values from a function and setting error flags, i am currently using the following approach:

bool fine = true;
fine &= func1();
fine &= func2();
.. and so on.

if (!fine)
{
    // error 
}

Could anyone please let me know if there is a neater(better?) way to do the same?

Thanks in advance!

  • 5 Contributors
  • 5 Replies
  • 222 Views
  • 21 Hours Discussion Span
  • Latest Post Latest Post by myk45

Dani AI

Generated

Several useful directions already appear in the replies; the main architectural choice is whether to fail fast (stop on the first error) or to run all checks and collect every failure. The original single-bool approach from (combining results into one flag) will indeed call every function when using a bitwise combine, which is sometimes desirable but often surprising. 's && suggestion short-circuits and is the right fit when later steps depend on earlier ones. is correct to warn against a lone bool when multiple independent error flags are needed.

When the goal is "collect all failures" and also know which steps failed, use a bitmask, bitset, or a container of messages instead of a single bool. For example:

const unsigned STEP1 = 1u << 0;
const unsigned STEP2 = 1u << 1;
unsigned errors = 0;

if (!checkStep1()) errors |= STEP1;
if (!checkStep2()) errors |= STEP2;

if (errors) {
  // inspect bits or map bits -> messages
}

For richer diagnostics, accumulate structured errors (vector of strings or small error objects) so callers can report context. If the behavior should stop on the first problem (fail fast), prefer short-circuiting (&&) or an explicit loop with break so expensive or dependent operations are not run.

Exceptions (as suggested by and ) are appropriate when an error is truly exceptional or when automatic stack unwinding and propagation are needed; they are not a replacement for normal control-flow checks in hot paths or low-level APIs. For robust APIs consider typed error returns (enum + message, std::error_code, or an outcome/expected-style wrapper) so failure reasons are explicit and testable.

Practical rules: name flags clearly (all_ok, errors), document whether later calls run after a failure, choose fail-fast vs collect-all deliberately, and prefer structured errors over opaque bools in production code.

Recommended Answers

All 5 Replies

Member Avatar for deceptikon

I wouldn't use bool for a bitset of error flags, but that approach isn't bad. In fact, iostream implementations will typically use it for the error state of a stream.

What kind of errors are these? Have you considered exceptions?

Member Avatar for Eagletalon

I agree... its a decent way to check the outcome of your functions... alternatively you can use a try catch... but it comes down to the same

Member Avatar for Despairy

I would suggest the try catch method.
just inserting all those function calls into one TRY statement
and each could throw a different warning class to be caught on the outside

that way instead of running all the function you could stop after the first error.
but that depends on your needs .

good luck

Member Avatar for L7Sqr

If each of the calls depends on the previous one rturning a true value then you can use the && operator to chain them. Something like:

if ( func1() && func2() && func3() && func4() ) {
   std::cout << "Success!" << std::endl;
} else {
   std::cout << "Error at some point in the chain" << std::endl;
}

However, this leaves you with no way to determine where the failure occurred. That may or may not present a problem for your scenario.

Member Avatar for myk45

Hello All, thanks a lot for the suggestions!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.