Well I described an approach how to structure code to avoid checking object states (error handling) most of the time. For example, when you use a FILE like hand

Well I described an approach how to structure code to avoid checking object states (error handling) most of the time. For example, when you use a FILE like handle to write to a file stream or similar, you don't have to check each time you call fwrite(). It's the opposite, it's sufficient to check at the very end (if you're interested at all). The way I've been writing code for the last 2 years or so, there is almost no error handling at all. I check buffer ranges whenever I'm writing directly to memory using a pointer + capacity / size pair. I could probably avoid that as well with some C++ magic but even that is rare enough that I don't even bother. Most of the other error checks are in the application setup / teardown code in the hull of the application - typically one check per codebase per error or object type. Nothing to worry about, I would have to do just as much work with RAII or any other mechanism. The easiest way to handle an error, for a statically set up object, is to attach it to the "process object" i.e. exit() immediately. The next easiest way is to attach the error to some subordinate state object, where the appropriate subsystem can later pick the error up and reset the object or take appropriate action. I've already had my phase of wasted months and years composing monads and frankly I don't want to get back there but would rather get real work done. In practice, working with monads amounts to a lot of headaches how to wrap, unwrap, and lift things that I could have simply written as straightline code in a non-fancy language, after spending some reasonable thought when and what things should actually best happen. If you need complicated type hackery to automate writing error handling code, what you are doing is... too complicated.