5 ms·
It's remarkable to me how many codebases ban exceptions and yet, somehow, people still insist they're good.
by jesse__ 9mo ago
It's remarkable to me how many codebases ban exceptions and yet, somehow, people still insist they're good.
- tester756 9mo agoThey're good for exceptional situations where foundamental, core assumptions are broken for some reason. In such scenario there's no error recovery, software is expected to shutdown and raise loud error.
- dijit 9mo agoI use asserts for this purpose.
- jesse__ 9mo agoIf you're planning on shutting down, what's the fundamental difference between throwing an exception, vs simply complaining loudly and calling exit() ..?
- trinix912 9mo agoSometimes it’s useful to handle the exception somewhere near its origin so you can close related resources, lockfiles, etc. without needing a VB6 style “On Error GoTo X” global error handler that has to account for all different contexts under which the exceptional situation might have occurred.
- PhilipRoman 9mo agoYour process can crash or be killed at any moment anyway. Depending on in-band cleanup is not reliable.
- nomel 9mo agoSure, but there are many cases where you don't have to halt because you can cleanup and carry on.
- matheusmoreira 9mo ago> a VB6 style “On Error GoTo X” global error handler that has to account for all different contexts under which the exceptional situation might have occurred ... That seems like a pretty accurate description of how exception handling mechanisms are implemented under the hood. :)
- einpoklum 9mo agoThe code that's throwing an exception typically does not know that the exception catcher will shut anything down. And - very often, you would _not_ shut down. Examples: * Failure/error in an individual operation or action does not invalidate all others in the set of stuff to be done. * Failure/error regarding the interaction with one user does not mean the interaction with other users also has to fail. * Some things can be retried after failing, and may succeed later: I/O; things involving resource use, etc. * Some actions have more than one way to perform them, with the calling code not being able to know apriori whether all of them are appropriate. So, it tries one of them, if it fails tries another etc.
- ljm 9mo agoYet, if you can only explain an exception using the word ‘exception’ you’re not making any head way. I like the idea of an exception as a way to blow out of the current context in order for something else to catch it and handle in a generic manner. I don’t like the idea of an exception to hide errors or for conditional logic because you have to know what is handling it all. Much easier to handle it there and then, or use a type safe equivalent (like a maybe or either monad) or just blow that shit up as soon as you can’t recover from the unexpected.
- spacechild1 9mo ago> They're good for exceptional situations where foundamental, core assumptions are broken for some reason. No, that's what assertions or contracts are for. Most exceptions are supposed to be handled. The alternative to exceptions in C++ are error codes and `std::expected::. They are used for errors that are expected to happen (even if they may be exceptional). You just shouldn't use exceptions for control flow. (I'm looking at you, Python :)
- wvenable 9mo agoLooking at this ban list, they've removed everything from C++ that makes it fun. Come on people, who doesn't love a little std::function?!? On banning exceptions:"Things would probably be different if we had to do it all over again from scratch." https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions
- pkasting 9mo agoWe have base::Callback for when you'd reach for std::function, which provides superior safety.
- BeetleB 9mo ago> Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. ... Things would probably be different if we had to do it all over again from scratch. They are clearly not against them per se. It simply wasn't practical for them to include it into their codebase. And I think a lot of the cons of exceptions are handled in languages like F#, etc. If f calls g which calls h, and h throws an exception, the compiler will require you to deal with it somehow in g (either handle or explicitly propagate).
- jesse__ 9mo agoMy issue with exceptions is also practical. If they didn't introduce significant stability issues, I'd have no problem. As it stands, it's impossible to write robust software that makes use of C++ exceptions. > the compiler will require you to deal with it somehow in g I agree, this is the sensible solution.
- azov 9mo agoMost codebases that ban exceptions do it because they parrot Google. Google’s reasons for banning exceptions are historical, not technical. Sadly, this decision got enshrined in Google C++ Style Guide. The guide is otherwise pretty decent and is used by a lot of projects, but this particular part is IMO a disservice to the larger C++ ecosystem.
- alextingle 9mo agoI agree. I've worked on large C++ code bases that use exceptions, and they've never caused us any real problems.
- ryandrake 9mo agoI think reasonable people can disagree about whether C++ exceptions are "good" or not. There are things you can't do easily in C++ without using exceptions, like handling errors that happen in a constructor and handling when `new` cannot alloc memory. Plus, a lot of the standard library relies on exceptions. And of course there's the stylistic argument of clearly separating error-handling from the happy-path logic. I won't argue that it's popular to ban them, though. And often for good reasons.
- canucker2016 9mo agoFor exception-less C++, you'd declare an operator new() that doesn't throw exceptions and just returns NULL on allocation failure along with a simple constructor and a followup explicitly-called init() method that does the real work which might fail and returns an error value on failure.