[HN Gopher] Banned C++ Features in Chromium
       ___________________________________________________________________
        
       Banned C++ Features in Chromium
        
       Author : szmarczak
       Score  : 55 points
       Date   : 2026-01-23 20:27 UTC (2 hours ago)
        
 (HTM) web link (chromium.googlesource.com)
 (TXT) w3m dump (chromium.googlesource.com)
        
       | Night_Thastus wrote:
       | Nothing particularly notable here. A lot of it seems to be 'We
       | have something in-house designed for our use cases, use that
       | instead of the standard lib equivalent'.
       | 
       | The rest looks very reasonable, like avoiding locale-hell.
       | 
       | Some of it is likely options that sand rough edges off of the
       | standard lib, which is reasonable.
        
       | dfajgljsldkjag wrote:
       | The banned list proves that context matters more than having the
       | newest tools. These features work well for small apps but they
       | cause problems in a project this size.
        
       | ddtaylor wrote:
       | Exceptions are banned, but an exception is made for Windows.
        
         | refulgentis wrote:
         | grep'd "exception" and "Windows", tl;dr only Windows reference
         | is for `[[no_unique_address]]`. Therefore I am probably missing
         | a joke :)
        
           | jesse__ wrote:
           | Might be referring to SEH ..? Just a wild guess
        
             | refulgentis wrote:
             | Ah, found it: in the style guide linked from this article. 
             | https://google.github.io/styleguide/cppguide.html#Exception
             | s
        
       | jesse__ wrote:
       | It's remarkable to me how many codebases ban exceptions and yet,
       | somehow, people still insist they're good.
        
         | tester756 wrote:
         | They'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 wrote:
           | I use asserts for this purpose.
        
           | jesse__ wrote:
           | If you're planning on shutting down, what's the fundamental
           | difference between throwing an exception, vs simply
           | complaining loudly and calling exit() ..?
        
             | trinix912 wrote:
             | Sometimes 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 wrote:
               | Your process can crash or be killed at any moment anyway.
               | Depending on in-band cleanup is not reliable.
        
         | wvenable wrote:
         | Looking at this ban list, they've removed everything from C++
         | that makes it fun.
         | 
         | 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
        
         | BeetleB wrote:
         | > 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__ wrote:
           | 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.
        
           | heyitsdaad wrote:
           | The "pros" list is exceptionally weak. This was clearly
           | written by someone who doesn't like exceptions. Can't blame
           | them.
        
           | jandrewrogers wrote:
           | 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.
        
             | BeetleB wrote:
             | > 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.
        
             | matheusmoreira wrote:
             | 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 better shape:
             | 
             | https://youtu.be/LorcxyJ9zr4
        
             | beached_whale wrote:
             | 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
        
           | jayd16 wrote:
           | 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?
        
             | BeetleB wrote:
             | 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.
        
         | azov wrote:
         | Most 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 quite decent and is used by
         | a lot of projects, but this particular part turned out pretty
         | toxic for larger C++ ecosystem.
        
       | WalterBright wrote:
       | Modules are banned - they should have just copied D modules.
        
       ___________________________________________________________________
       (page generated 2026-01-23 23:00 UTC)