5 ms·
> Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. ... Things would probably be different if we had
by 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.
- yunnpp 9mo agoWhat stability issues?
- rauli_ 9mo agoUnchecked exceptions will eventually lead into programs crashing because some developer forgot to catch specific type of exception somewhere.
- drysine 9mo agoAnd developers never forget to check error codes.
- dan00 9mo agoLooking at code, it‘s easier to spot the missing check for an error code, than a not catched exceptions. Also error codes are part of the signature of a function, which exceptions aren‘t.
- drysine 9mo agoIf you need to wrap each call in try/catch, it's better to use return codes in some form or rethink the approach.
- listeria 9mo agomay I introduce you to the nodiscard attribute[1]? enum (class)? [[nodiscard]] Error { Ok, NoMem, ... }; [1]: https://en.cppreference.com/w/cpp/language/attributes/nodiscard.html https://en.cppreference.com/w/cpp/language/attributes/nodisc...
- drysine 9mo agoC attribute: nodiscard (since C23) [1] https://en.cppreference.com/w/c/language/attributes/nodiscard https://en.cppreference.com/w/c/language/attributes/nodiscar...
- senderista 9mo agoFWIW I’ve been using warn_unused_result in both gcc and clang since about 2020.
- drysine 9mo agoYep, partial remedies are available for quite some time.
- ahtihn 9mo agoThat seems like a better outcome than continuing when an error happened while thinking everything succeeded?
- yunnpp 9mo agoYes, but that's not a dichotomy. Languages like Java have function declare what exceptions they throw, and the caller must either catch it or also declare that it throws it. Gets cumbersome quickly, but I believe it's for the best to encode exceptions at the type system.
- heyitsdaad 9mo agoThe “pros” list is exceptionally weak. This was clearly written by someone who doesn’t like exceptions. Can’t blame them.
- jandrewrogers 9mo agoIn low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability. Exceptions in high-level languages avoid many of these issues by virtue of being much further away from the metal. It is a mis-feature for a systems language. C++ was originally used for a lot of high-level application code where exceptions might make sense that you would never use C++ for today.
- BeetleB 9mo ago> In low-level systems software, which is a primary use case for C++ I can assure you: Most C++ SW is not written for low-level. > exceptions can introduce nasty edge cases that are difficult to detect and reason about. That's true, except for languages that ensure you can't simply forget that something deep down the stack can throw an exception. BTW, I'm not saying C++'s exceptions are in any way good. My point is that exceptions are bad in C++, and not necessarily bad in general.
- beached_whale 9mo agoThe model of communicating errors with exceptions is really nice. The implementation in C++ ABI's is not done as well as it could be and that results in large sad path perf loss.
- jandrewrogers 9mo ago> That's true, except for languages that ensure you can't simply forget that something deep down the stack can throw an exception. Sometimes it is not safe to unwind the stack. The language is not relevant. Not everything that touches your address space is your code or your process. Exception handlers must have logic and infrastructure to detect these unsafe conditions and then rewrite the control flow to avoid the unsafety. This both adds overhead to the non-exceptional happy path and makes the code flow significantly uglier. The underlying cause still exists when you don't use exceptions but the code for reasoning about it is highly localized and usually has no overhead because you already have the necessary context to deal with it cleanly.
- jayd16 9mo agoIs this correct? I don't know F# but I thought it had unchecked exceptions. How does it handle using C# libs that throw unchecked exceptions?
- BeetleB 9mo agoMy memory of F# is very rusty, but IIRC, there are two types of error handling mechanisms. One of them is to be compatible with C#, and the other is fully checked.
- lateforwork 9mo agoUnchecked exceptions is a design flaw of C# see here: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-exception-handling-falls-short-f7f932488aba https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...
- pasc1878 9mo agoI usually see articles saying that Java checked exceptions are bad. e.g. https://www.javacodegeeks.com/2026/01/javas-checked-exceptions-the-20-year-experiment-that-failed.html https://www.javacodegeeks.com/2026/01/javas-checked-exceptio...
- MRtecno98 9mo agoBecause java is garbage-collected and doesn't have any of the problems of C++ exceptions, so checked exceptions just become a nuisance of having to try/catch everything.
- lateforwork 9mo agoYou don't have to try/catch everything.
- pasc1878 9mo ago