[thepicard]

>If the profession ever wants to produce anything reliable in C++

This has already been done, so you are obviously wrong.

Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.

Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has detailed descriptions of its possible throws, you won't get devs to read all the documentation for every function in some piece of code that needs a small fix.

[TheMiller]

> Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.

Exceptions do not "explode your call stack", and any function can fail in ways both documented and undocumented. Consistent use of exceptions that derive from a small and well-chosen set of base classes means that callers can choose where and how to respond to categories of errors, instead of being forced to litter all code with error handling conditionals. I have worked on large applications that made the transition to using exceptions, and when combined with strict RAII and other best practices, the effect is absolutely to make code easier to understand and much more robust.

[iribe]

The key is "small and well chosen set of base classes" for your exceptions. This is where you got the most benefit, and you probably know it. Without exceptions, you can have a class that represents well defined state such as either success or an error code, with the error code being well defined, returning an object of this class for all methods that need to return success/failure codes, and requiring that it be handled, so compilation fails if callers ignore the return value.

What's great about this is I might call a method that simply concatenates two strings, that is all it does, and I know this won't fail(OOM can always happen, but good luck recovering from that), so I don't return a status. I can call this method assuming no failure and no boiler plate is needed. With exceptions, there's always that possibility that an exception can be thrown. What if I call this method from code that needs to close resources? Great, now I absolutely must have RAII for cleanup, which is more complicated than just doing close(x). Also, what are you going to do when using 3rd party code with its own base exception class? Now, at the upper layers of your code, you have to have a handler for each base class. Without exceptions, someone might have their own status object they return, and I'll need to translate that, else my code won't compile. Your code will compile even though you might not handle that 3 party base exception class.

Of course, most times code just propagates the error up so that adds to boiler plate without exceptions.

I think the talk of using exceptions vs returning a status is a red herring. They have their positives and negatives, and we can argue this until the cows come home. The most important thing is to use a set of well defined success/error codes, whether this comes from exceptions or a returned status isn't really important. I've seen codebase with C++ exceptions working just fine, and I've seen c++ code with no exceptions, and it worked well. The commonality between these two cases is .... well defined error codes.

[alexk7]

Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you start to understand the huge advantage they give: your code shrinks by an order of magnitude vs the same code with manual error propagation.