If thrown exceptions in constructors can lead to memory leaks or partially-constructed objects, then why we don't make them atomic? so neither an object nor it's local variables will get created/allocated if an exception was thrown. Is there a reason why constructors are not designed that way?

  • 4
    Is this C++ or C# or Java? -- they're different.
    – Erik Eidt
    Jul 11 at 13:50
  • Atomicity is hard to achieve
    – Caleth
    Jul 11 at 19:45
  • Why don't we make all code atomic?
    – user253751
    Jul 13 at 10:21
  • @user253751 I don't know, why?
    – Rain
    Jul 13 at 20:15
  • @ErikEidt Well, you are right they are different. Although, each language has it's own way to solving the problem I mentioned, none of them to my knowledge implements atomic constructor. That's the reason I tagged all of them, also I wanted to gain more attention/ideas from all these languages programmers. My assumptions might be wrong after all, but I don't see why this question needs to be more focused since I asked a clear question about what is seems (to me) as a language-agnostic question.
    – Rain
    Jul 13 at 20:41

Usually, it is a best practice to write constructors so that they should not have any side effects and external interactions. Just initialize the members of the object using only the parameters passed to them and do all of the complex operations in a separate function once the object was safely constructed. Or even better, let the only way for constructing an object be a factory function, that can check the parameters for correctness and only create the object if it can be sure it will be valid/consistent/safe to use.

Allowing constructors to do much more than that might have its roots both in history and in offering powerful options to developers (though these overlap a lot).

On the "being powerful" side: Most programming languages prefer to offer many possibilities for developers, instead of restricting what they can do for a simple reason: If you would need to do something the language does not support you will use a different language ... but if you have much more power than needed, you can always decide to be careful and not use it.

On the "historical" side: Technically, constructors have been just simple functions for a long-long time with some additional rules. This made them easy to implement for compiler developers (other some extra checks they could just reuse the usual procedures used for functions), but also offered all of the powers of "normal" functions.

  • In C++ one of the main precepts is RAII - so resource allocation is usually done in the constructor (which makes the constructor not atomic). Are you saying that resource allocation shouldn't be done in the constructor? Jul 12 at 23:47
  • Both can work. In the case of C++ RAII is used frequently. As the object is wrapping the resource, it is both safer then just calling new and probably easier to read too. On the other hand, when using RAII it is usually important to keep in mind, that if the exceptions thrown during resource allocation were not handled properly, the constructor might not have successfully finished (throwing the exception) ... potentially leading to an object that is not "living". That is its destructor might not be called when it goes out of scope, as it never existed. Jul 13 at 7:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.