Cascading bool returns, bad error handling practice?

When making my hobby projects I've typically used a system where certain functions return true or false values to indicate if an error occurred.

For Example: main calls class A, class A has a function called bool setup(). Class A has a member class C, which also needs to setup some stuff and has a bool load() function.

now with the given structure, I have to have an if/then statement when using C::load() inside the setup(). Main calls setup() so I have to use an if/then statement to evaluate it ad decide whether to go on or not.

What I'm asking is this cascading bool checking a waste of time or do exceptions correct that problem.

I've found that with exceptions a similar problem can occur where main has to try and catch exceptions thrown from setup(), which in turn has to try and catch exceptions thrown from load(). It's a similar process but with try/catch statements instead of if statements.

What is the "proper" method of error handling in the case of multiple programs or functions cascading errors down to base calling functions.

Instead of setting up objects after construction you should probably do the setup in the constructor of the class. If possible, make sure that an object is always in a normal, usable state; that is, no need to call special functions in a particular order to make them so.

If you do so, you are almost left with exceptions. They are different from passing bools around in that you can choose where to catch them - not necessarily directly in the calling function. And they can convey more information about the error than bools do.

(You can alternatively have a function that must be called straight after the constructor, to make sure the object is OK - like fstreams work).

I wouldn't probably worry about wasting time, unless your program is feelably slow and you have reason to believe that error handling is slowing it down. (But what would you do, if these really are error conditions you need to check?)

It depends on the situation. Can the setup call fail often? If yes, then returning true or false makes sense. If it doesn't fail often, then throwing an exception makes sense.

If you use exceptions, you don't have to have a try/catch block in each level of code. In fact, that's the wrong way to use exceptions. The entire point of switching to exceptions would be so that the setup() function (or constructor) could throw the exception, and the load() code can ignore the possibility of setup() failing completely. The main() code is where you would catch the exception.

That means that you just call setup() and assume it works. The code that calls load() just calls it and assumes it works. If any function has an unusual failure, it will throw an exception that will propagate out and be handled near the beginning of the progam.

You'll have to make sure you are using good RAII techniques if you do this, but you should be doing that anyway.

Now about resolution. I know that leaving an exception ynhandled causes program interruption but is it reasonable that a caught exception not resolve it, but just stop execution and output the error, or generally should the caught resolution actually resolve. Lets say in main you tried and caught an exception for a problem in load() and rather than stop execution and give an error it would loop and redo whatever action necessary to resolve the problem, even if causes a sort of wasteful call to the "middle" class function even if nothing went wrong on that level?

The code that can handle the exception is the place it should be caught. So if you have main() which calls run() which calls init() which calls load() which calls setup(), and setup() throws an InitFileNotFound exception, then maybe init() knows how to generate a default ini or inform the user that the init file was corrupted or missing. So then the init() function would catch the exception and attempt to handle it. If it can't handle it, then it can re-throw the exception, or just exit with a failure, or throw a different exception, whatever is appropriate for errors from that function.

In the end, any exception you throw should be caught somewhere. At the very least, you should probably catch the exceptions in main() indicate that an error occurred and the program is closing.

Whether a handler continues the program or aborts it is a question of whether it can recover. If init() fails and main() catches the error, chances are that it doesn't know how to make init() succeed. The best it can do is tell the user that an error occurred and exit.