4 ms·

Performing an operation that can fail in a constructor or destructor will you into trouble. It's a trap. You can check for initialization failure ("remember to

by kabdib 6y ago

Performing an operation that can fail in a constructor or destructor will you into trouble. It's a trap. You can check for initialization failure ("remember to call isObjectOkay()" or something like that) but you're basically hosed if a destructor fails. No, exceptions are not the answer. NONE of the C++ projects I've worked on in the last 30+ years have used those in production. Exceptions are far, far worse trap. It's funny that the teams across half a dozen companies I've been in have independently come up with just about the same set of guidelines about C++ features. It's almost like some of those features were bad ideas. :-)

deleted 6y ago
[deleted]
int_19h 6y ago
Performing an operation that can fail in a constructor is not a problem, because then the initializer throws, and you don't get an object at all - so there's nothing for you to check if it's in a valid state or not. On the other hand, this is exactly the problem that arises if you refuse to use exceptions, because then the constructor has no way to signal that it failed. Since constructors, by their very nature (acquiring resources, validating initializers etc), can fail, you have to resort to "is it valid?" flags, and your API clients have to check those flags or risk unspecified behavior.
- kabdib 6y ago
  Using C++ exceptions is just not acceptable in large, production systems. I've worked on several C++ systems with tens of millions of lines of code. Different teams independently reached the conclusion that exceptions were destabilizing, and hid bugs and failures. Take a look at the Google C++ guidelines, as an example. https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions They're fine in other languages (python, etc.). Note that golang does not really have them, except in a very crude sense.
  - deleted 6y ago
    [deleted]
  - aprdm 6y ago
    The conclusion in google's page has nothing to do with bugs and failures. They mention how it would be better to use it but for practical reasons (read big legacy code base) it isn't feasible.
  - int_19h 6y ago
    I've worked on several large production systems written in C++ that use exceptions throughout. Don't assume that your personal experience is the norm across the entire industry. The Google C++ style guide is (unfortunately) popular, but it still covers the minority of C++ projects overall, and there's plenty of criticism of it around, including from large teams working on production systems. I will also add that, from my past experience working on codebases that didn't or couldn't use exceptions (e.g. across C ABI boundary), the lack of exceptions, and people forgetting to check error codes, or propagating them improperly, was a very common source of hidden bugs.
  - ncmncm 6y ago
    > Using C++ exceptions is just not acceptable in large, production systems. This is a wholly false statement. Exceptions are used almost everywhere C++ is used. Google is a peculiar outlier, and suffers for it. You can read right in the cited document why they were obliged to give up using exceptions. It imposes huge costs which Google happens, by virtue of monopoly status, to be equipped to afford.

by kabdib 6y ago

deleted 6y ago

[deleted]

int_19h 6y ago

Performing an operation that can fail in a constructor is not a problem, because then the initializer throws, and you don't get an object at all - so there's nothing for you to check if it's in a valid state or not. On the other hand, this is exactly the problem that arises if you refuse to use exceptions, because then the constructor has no way to signal that it failed. Since constructors, by their very nature (acquiring resources, validating initializers etc), can fail, you have to resort to "is it valid?" flags, and your API clients have to check those flags or risk unspecified behavior.

kabdib 6y ago
Using C++ exceptions is just not acceptable in large, production systems. I've worked on several C++ systems with tens of millions of lines of code. Different teams independently reached the conclusion that exceptions were destabilizing, and hid bugs and failures. Take a look at the Google C++ guidelines, as an example. https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions They're fine in other languages (python, etc.). Note that golang does not really have them, except in a very crude sense.
- deleted 6y ago
  [deleted]
- aprdm 6y ago
  The conclusion in google's page has nothing to do with bugs and failures. They mention how it would be better to use it but for practical reasons (read big legacy code base) it isn't feasible.
- int_19h 6y ago
  I've worked on several large production systems written in C++ that use exceptions throughout. Don't assume that your personal experience is the norm across the entire industry. The Google C++ style guide is (unfortunately) popular, but it still covers the minority of C++ projects overall, and there's plenty of criticism of it around, including from large teams working on production systems. I will also add that, from my past experience working on codebases that didn't or couldn't use exceptions (e.g. across C ABI boundary), the lack of exceptions, and people forgetting to check error codes, or propagating them improperly, was a very common source of hidden bugs.
- ncmncm 6y ago
  > Using C++ exceptions is just not acceptable in large, production systems. This is a wholly false statement. Exceptions are used almost everywhere C++ is used. Google is a peculiar outlier, and suffers for it. You can read right in the cited document why they were obliged to give up using exceptions. It imposes huge costs which Google happens, by virtue of monopoly status, to be equipped to afford.