4 ms·
Exceptions are banned, but an exception is made for Windows.
by ddtaylor 9mo ago
Exceptions are banned, but an exception is made for Windows.
- refulgentis 9mo agogrep'd "exception" and "Windows", tl;dr only Windows reference is for `[[no_unique_address]]`. Therefore I am probably missing a joke :)
- jesse__ 9mo agoMight be referring to SEH ..? Just a wild guess
- refulgentis 9mo agoAh, found it: in the style guide linked from this article. https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions
- pjmlp 9mo agoPeople that keep bringing this up always miss the rationable that Google code was written initially in a C style that isn't exception safe. Key takeaway => "Things would probably be different if we had to do it all over again from scratch." "On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions. Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden. Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch."
- 8n4vidtmkvmk 9mo agoI'm quite happy to NOT have exceptions. I think they're a mistake as a language feature. What we need is first -class support for returning errors and propagating them, like what zig does. The next best thing are those RETURN macros that Google uses.
- pjmlp 9mo agoHaving to support legacy code is a bummer. /s Zig remains to be seen how market relevant it turns out to be.
- hdjrudni 9mo agoYa, we don't know yet. Still sitting on zig but I like what I see so far.
- direwolf20 9mo agoIsn't that equivalent to exceptions but more verbose and slower?
- invl 9mo ago"first-class support for returning errors and propagating them" certainly sounds like exceptions! In fact, the compiler can even emit special tables that let the runtime completely skip over stack frames that don't need to do any cleanup during that propagation step! Some languages have even innovated new kinds of exceptions that you can throw but that you are admonished should almost certainly never be caught. Unfortunately even this is also better for tool support, a problem that using a bunch of macros solves. It's cool and good when a variable gets declared inside the guts of some macro expansion (and--critically--escapes those guts).
- hdjrudni 9mo agoIts not the same. You have to explicitly declare the errors and if you want to ignore/propagate them, you have to do so explicitly as well. You cant invoke a function and pretend it'll never fail. Also, try/catch with long try blocks and a the error handling at the very end is just bad. Which of the statements in the try is throwing? Even multiple perhaps? Each should be handled individually and immediately
- pkasting 9mo agoBoth parts of your sentence refer to the Google style guide. This doc isn't the Google style guide. It's the Chromium modern c++ features doc. We don't talk about exceptions or platform-specific stuff (save a note on [[no_unique_address]]) in this doc.