Hacker News Reader

Comment by BeetleB | Hacker News Reader

> 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).

View on HN

My 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.

What stability issues?

Unchecked exceptions will eventually lead into programs crashing because some developer forgot to catch specific type of exception somewhere.

And developers never forget to check error codes.

Looking 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.

If you need to wrap each call in try/catch, it's better to use return codes in some form or rethink the approach.

may I introduce you to the nodiscard attribute[1]?

  enum (class)? [[nodiscard]] Error {
    Ok,
    NoMem,
    ...
  };

[1]: https://en.cppreference.com/w/cpp/language/attributes/nodisc...

   C attribute: nodiscard (since C23)

[1] https://en.cppreference.com/w/c/language/attributes/nodiscar...

FWIW I’ve been using warn_unused_result in both gcc and clang since about 2020.

Yep, partial remedies are available for quite some time.

That seems like a better outcome than continuing when an error happened while thinking everything succeeded?

Yes, 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.

In 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.

> 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.

The 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.

> 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.

> Sometimes it is not safe to unwind the stack.

This where garbage collected languages shine.

Exceptions are actually a form of code compression. Past some break even point they are a net benefit, even in embedded codebases. They're "bad" because the C++ implementation is garbage but it turns out it's possible to hack it into a much better shape:

https://youtu.be/LorcxyJ9zr4

There is no such thing as the 'C++ implementation' of exceptions. Each vendor can do it differently.

C++ exceptions are fast for happy path and ABI locked for sad path. They could be much faster than they are currently. Khalil Estell did a few talks/bunch of work on the topic and saw great improvements. https://youtu.be/LorcxyJ9zr4

Oops, I meant they are ABI locked so sad path cannot be fixed.

If you forget to handle a C++ exception you get a clean crash. If you forget to handle a C error return you get undefined behavior and probably an exploit.

Exceptions are more robust, not less.

Yeap. forgetting to propagate or handle an error provided in a return value is very very easy. If you fail to handle an exception, you halt.

For what it's worth, C++17 added [[nodiscard]] to address this issue.

You should compare exceptions to Result-style tagged unions in a language with exhaustiveness checks, like Rust. Not to return codes in C, lmao.

Everyone (except Go devs) knows that those are the worst. Exceptions are better, but still less reliable than Result.

https://home.expurple.me/posts/rust-solves-the-issues-with-e...

> like Rust

Where people use things like anyhow.[0]

[0] https://docs.rs/anyhow/latest/anyhow/

Anyhow erases the type of the error, but still indicates the possibility of some error and forces you to handle it. Functionality-wise, it's very similar to `throws Exception` in Java. Read my post

As a matter of fact I did when it appeared on hn.

>forces you to handle it.

By writing `?`) And we get poor man's exceptions.

Poor man's checked exceptions. That's important. From the `?` you always see which functions can fail and cause an early return. You can confidently refactor and use local reasoning based on the function signature. The compiler catches your mistakes when you call a fallible function from a supposedly infallible function, and so on. Unchecked exceptions don't give you any of that. Java's checked exceptions get close and you can use `throws Exception` very similarly to `anyhow::Result`. But Java doesn't allow you to be generic over checked exceptions (as discussed in the post). This is a big hurdle that makes Result superior.

>Poor man's checked exceptions.

No, it's not quite the same. Checked exceptions force you to deal with them one way or another. When you use `?` and `anyhow` you just mark a call of fallible function as such (which is a plus, but the it's the only plus), and don't think even for a second about handling it.

Checked exceptions don't force you to catch them on every level. You can mark the caller as `throws Exception` just like you can mark the caller as returning `anyhow::Result`. There is no difference in this regard.

If anything, `?` is better for actual "handling". It's explicit and can be questioned in a code review, while checked exceptions auto-propagate quietly, you don't see where it happens and where a local `catch` would be more appropriate. See the "Can you guess" section of the post. It discusses this.

Rust is better here (by a lot), but you can still ignore the return value. It's just a warning to do so, and warnings are easily ignored / disabled. It also litters your code with branches, so not ideal for either I-cache or performance.

The ultimate ideal for rare errors is almost certainly some form of exception system, but I don't think any language has quite perfected it.

> you can still ignore the return value

Only when you don't need the Ok value from the Result (in other words, only when you have Result<(), E>). You can't get any other Ok(T) out of thin air in the Err case. You must handle (exclude) the Err case in order to unwrap the T and proceed with it.

> It also litters your code with branches, so not ideal for either I-cache or performance.

That's simply an implementation/ABI issue. See https://github.com/iex-rs/iex/

Language semantics-wise, Result and `?` are superior to automatically propagated exceptions.

> If you forget to handle a C++ exception you get a clean crash

So clean that there's no stack trace information to go with it, making the exception postmortem damn near useless.

> "In 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."

Interestingly, Microsoft C / C++ compiler does support structured exception handling (SEH). It's used even in NT kernel and drivers. I'm not saying it's the same thing as C++ exceptions, since it's designed primarily for handling hardware faults and is simplified, but still shares some core principles (guarded region, stack unwinding, etc). So a limited version of exception handling can work fine even in a thing like an OS kernel.

FWIW, I think it is possible to make exception-like error handling work. A lot of systems code has infrastructure that looks like an exception handling framework if you squint.

There are two main limitations. Currently, the compiler has no idea what can be safely unwound. You could likely annotate objects to provide this information. Second, there is currently no way to tell the compiler what to do with an object in the call stack may not be unwound safely.

A lot of error handling code in C++ systems code essentially provides this but C++ exceptions can't use any of this information so it is applied manually.

> In low-level systems software, which is a primary use case for C++

I don't this this is true. There is A LOT of C++ for GUI applications, video games, all kind of utilities, scientific computing and others. In fact, I find that the transition to "modern" alternatives from native GUI toolkits in C/C++ has led to a regression in UI performance in general. Desktop programs performed better 20 years ago when everything was written in Win32, Qt, GTK and others and people did not rely on bloated Web toolkits for desktop development. Even today you can really feel how much more snappy and robust "old school" programs are relative to Electron and whatnot.

To clarify, you think that low-level systems software is only a secondary use case for C++? The part you quoted does not make claims about whether there are other primary use cases, just that low-level systems software is one of them, so it's not clear why it being useful elsewhere is a rebuttal of that.

There are only so many OS kernels to be written. Nothing else is really low-level these days.

I don't think I agree with that. To me, how low-level something is makes more sense sense as a spectrum rather than a binary, and there are certainly other things that I'd consider to fit into the lower end than just OS kernels. Over the summer I contracted for a company making satellites working on software they had that facilitated interactions between various software and hardware components that had to run a 20 ms loop for processing everything, with delays cascading throughout those other components and causing systemic issues. This was all in userland (the OS stuff was managed by another team), but a tracing garbage collector would have been pretty much a non-starter due to the potential to miss the expected timing of a loop iteration.

You could handwave this objection by saying it's not "really" low level or that "nothing" was an exaggeration, but at that point it seems like we'd be back to the original question of why it's wrong to say that this isn't a primary use case for C++.

Is 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?

My 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.

Unchecked exceptions is a design flaw of C# see here: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

I usually see articles saying that Java checked exceptions are bad.

e.g. https://www.javacodegeeks.com/2026/01/javas-checked-exceptio...

Because 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.

You don't have to try/catch everything.

You do have to catch checked exceptions and that is the issue under debate.

No, you can just declare that the exception in the throws clause.

It really depends on how reliable you want the code to be. Many business application developers prioritize development speed and don't want to think about errors, for them checked exceptions may seem like a hassle. For developers who prioritize reliability unchecked exceptions are a huge problem because they are not part of the contract and can change without notice.

The “pros” list is exceptionally weak. This was clearly written by someone who doesn’t like exceptions. Can’t blame them.

Reply on news.ycombinator.com