I feel that the "error" handling is one of those "core things" that people have rarely fully understood. Especially newbies starting are often confused and thin

I feel that the "error" handling is one of those "core things" that people have rarely fully understood. Especially newbies starting are often confused and things get muddled. In all honesty it took me +10 years myself to reach some kind of clarity on this. Anyway I find it that when you lack that clarity your code will be quite messy (isn't this always the case?) and things will get muddled. And since error handling is so precarious your implementation quality will suffer considerably. So below is my take on this with 3 clear labels and guidelines on how to apply. Hope this helps. There are 3 kinds of "errors". 1. Bugs. - created by programmer. - invalid state of the application - >it has transcended it's own logical realm and you can't reason about its behaviour anymore. - null pointers, OOB, etc. 2. Errors that are "expected" part of the program execution. - you need to write logic flow to deal with this - it's expected and quite normal that this might happen - incorrect (user) input, file not found, socket timed out etc. - this is really just an error from the end user's perspective. 3. Errors that are "unexpected". - some very unexpected error - system resource allocation failed, out of memory, out of file handles etc. - critical resource was not accessible (for example a "must have" config file was not found) How to deal with these? 1. Abort and dump core. Yep seriously, just do it. Blow up with a bang and leave a stack trace that you can analyze in the post-mortem debugger and see what went wrong. As a result your application will be simpler and more straightforward. Simply, don't try to write logic to deal with programmer failures. It will just clutter your program, mask the problem and make fixing it harder. int divide(int x, int y) { if (y == 0) { throw std::string("Divide by zero"); } return x / y; } passing y=0 the function is clearly a bug. It'd be much better to core dump here. Unless the function was designed with double purpose of validating the input and performing the actual function. I'd much rather split these into two different functions, since the core function may be called from different contexts, some of which might not require any input validation at all even. And the validation function clearly should not be using exceptions either since it's quite normal and expected that input from external sources (such as the user) can be malformed and you probably want to write logic that then bashes (sorry.. informs) the user about their wrong input. 2. Use error codes. 3. Use exceptions.