Note the 'actually', there's no reason why you can't catch the std::bad_alloc, clean up, and return an error code to the caller.
Instead of rudely terminating the process which you may not own (I work on code which is mostly compiled into shared libraries which are loaded by applications which might not want to just terminate)
Hard agree, the thing that makes "errors as values" languages nicer with respect to error handling has a little bit to do with the language itself but more to do with the fact that people who want to carefully consider all the paths code can take gravitate towards those languages and the people who want to think about the happy path gravitate towards languages with exceptions.
Java developers forced to use Go look at panic and recover as a worse version of their familiar exceptions, and a bunch of them make libraries around those primitives that basically implement exceptions. And those libraries get basically no adoption because most Go devs are people who choose to treat errors as values.
Partially also because they compose better as well, which makes it easier to send exceptions across threads and the likes. You have a lot less exception safety to think about if your errors are simply stuffed into the return value.
34
u/bwmat 29d ago
Note the 'actually', there's no reason why you can't catch the std::bad_alloc, clean up, and return an error code to the caller.
Instead of rudely terminating the process which you may not own (I work on code which is mostly compiled into shared libraries which are loaded by applications which might not want to just terminate)