The problem comes when programmers muddle and get confused about different possible "failure/error" conditions in a program. A) Bugs, i.e. errors made by the p

The problem comes when programmers muddle and get confused about different possible "failure/error" conditions in a program. A) Bugs, i.e. errors made by the programmers of the software B) Expected logical conditions that only appear as "errors" to the users C) Unexpected failures such as resource allocation failures Let's have a look at these one by one. Case A, i.e. bugs written by programmer, i.e. the program is about to violate it's own constraints/logic/pre/postconditions/invariants. Examples are many, but for example off by one, accessing nullptr/null object, array out of bounds etc. Really the best way to deal with these is to abort/panic/dump core with a loud bang and produce a core dump and a stack trace to simplify debugging. Case B, i.e. conditions that the application should expect to encounter and be prepared to deal with. For example your TCP socket connection times out, DNS query fails, HTTP query response returns 404. In any such case when you need to write some logic such as "retry to open the sockect connection" or "tell the user that the resource was not foudn" or try to resolve DNS query again later the best method is to use some kind of error enum/number/code kind of system. And to recap the "errors" in this category are not errors for the software but only errors for the user. I.e. for the software these are just logical conditions. Finally Case C), errors that are neither A or B. Typically these are just some very unexpected conditions such as resource allocation failures. Your program failed to allocate a socket or pipe or a mutex or whatever. Should not happen but might happen once in a blue moon under heavy system load or unexpected conditions. These are the things you don't want to conflate with your logical "error condition" path from case B because't that won't scale and propagation of errors up the stack becomes very tedious. These are best suited for exceptions. Edit: Note that this isn't a static state but what is considered a bug or a logical error can change across modules depending on the software project organization. A module written by another team migth consider illegal arguments as "Logical error conditionds" and return error codes, whileas a similar module written and used within a single team might just consider this a bug and dump core.