Exception performance is pretty obvious: you need to unwind the stack everytime you catch an exception whereas checking an error return value is one instruction long.
If you try to catch your exception at every statement, you're not using RAII correctly.
Returns values are less bug prone because behaviour is obvious (boost::system::error_code is a good way to encapsulate information).
Exception is a goto statement because basically you're breaking the flow and saying "go to catch in case of error".
For all these reasons, exceptions should be exceptional.
Use exceptions for abnormal behavior that you cannot properly handle in the program (out of memory, i/o error...).
Exception performance is pretty obvious: you need to unwind the stack everytime you catch an exception whereas checking an error return value is one instruction long.
It's not obvious at all. You need to unwind the stack anyway. If you do so using some form of jump table when an exception is thrown, you only have a single step to deal with instead of a whole series of returns. Moreover, on the non-exceptional path, you no longer need check-and-branch logic after the return from every function that might fail.
If you try to catch your exception at every statement, you're not using RAII correctly.
Sure, but that doesn't imply your conclusion that usually you would only want one try/catch per thread. Why can't we catch an exception at whatever level of our code knows how to respond to that situation? Why would we assume that the only levels of logic in our code are low-level work that might throw and a top-level oversight loop?
Returns values are less bug prone because behaviour is obvious (boost::system::error_code is a good way to encapsulate information).
C++ does non-obvious things all the time, and that can be helpful because it removes unnecessary details so that we can concentrate on the logic that matters. Would you also argue that using RIAA is bad because if we explicitly released all our resources before every possible return from the function it would make the behaviour obvious?
Exception is a goto statement because basically you're breaking the flow and saying "go to catch in case of error".
Except that you're not just saying "goto catch", are you? Like return, continue and break statements, exceptions can only transfer control to another location in a structured way, in this case, the equivalent of returning early from the lower-level functions and going back up the call stack. You can't escape the structured programming roots of the code using an exception the way you can with goto, and the semantics of unwinding the stack when an exception is thrown are well defined and widely understood.
For all these reasons, exceptions should be exceptional.
Use exceptions for abnormal behavior that you cannot properly handle in the program (out of memory, i/o error...).
Sure, that's one useful role for exceptions, but why should we limit our use of a tool based on what the tool happens to be called? I don't think they had modern C++ libraries and metaprogramming in mind when they added templates to the language.
If you try to catch your exception at every statement, you're not using RAII correctly.
Returns values are less bug prone because behaviour is obvious (boost::system::error_code is a good way to encapsulate information).
Exception is a goto statement because basically you're breaking the flow and saying "go to catch in case of error".
For all these reasons, exceptions should be exceptional.
Use exceptions for abnormal behavior that you cannot properly handle in the program (out of memory, i/o error...).