3 ms·

Exceptions are not just data, at least not if you do not always catch them immediately (in which case they are just pointless). They introduce additional contr

Exceptions are not just data, at least not if you do not always catch them immediately (in which case they are just pointless). They introduce additional control paths which are hard to reason about. In many languages these are not even explicit. Exceptions require an additional syntax to handle them. And having exceptions requires significant language infrastructure and comes with a huge toll on the structure of software projects. See my topmost comment. > In your example with parallel processing, you could throw an error as exception, let it unwind the whole stack, catch it and return as the result of the task. Which would catch only the first encountered error per thread. And not catch all the other errors that we could encounter and report after that.

gdy 8y ago
Well, if you don't have exceptions, stack unwinding, RAII, you've got to manually code the same sort of logic using repetitive code. Or you would have to change your design to minimise the pain of hand-coding stack unwinding, most likely paying a price for that in form of damaging other aspects of design. In other words, NOT having exceptions, IMO, results in having to write a huge amount of code accomplishing a trivial task - aborting some unit of functionality upon unexpected error. "And not catch all the other errors" I think, in most cases after an unexpected error happens it doesn't make sense to continue the task and report more errors, most likely induced by the first error. Don't get me wrong, there are plenty of cases when returning errors as values is the best fit and using the exceptions would be a disaster, but my point is that, IMO, the situation when errors abort tasks and are handled in more or less the same way is much more common.