2 ms·
No because I almost never use exceptions myself (unless consuming them). The only time I would really use it is if for some reason the constructor could fail,
by jgh 9y ago
No because I almost never use exceptions myself (unless consuming them). The only time I would really use it is if for some reason the constructor could fail, but usually in those cases there are better ways of designing the class. Otherwise it's error codes/reasons.
Honestly I'm not sure where to draw the line specifically, but I obviously err more on the side of "don't use them". Exceptions in C++ are costly and imo control flow gets all wonky with them...I find it's easier to reason about a program if the error handling is there with the rest of the logic instead of being a list of things that can happen at some point in the above code block.
- AstralStorm 9y agoAny error handling will make control flow explode into checks. Exceptions at least allow you to put the checks in the right place and not necessarily at the point where function is executed. In typical C code you get to propagate error check statements all the way everywhere or risk bugs. Or use central mechanism like errno and risk thread safety and overwrite while also not knowing about the source of the statement. In C++ you might have the same problem. Even std::optional (which defers the exception to actual value get) is not best as it loses the information on who made or set it...
- blub 9y agoCalling get on an empty optional is a programmer error though, not unlike dereferencing an invalid ptr, so throwing would be an improvement. :) Most code would check or call value_or, buggy code would throw. There's still the complication of the unsafe std::optional interface, which can only be solved by wrapping/rewriting IMO.