7

Possible Duplicate:
How to handle failure in constructor in C++?

Is there any pattern in C++ so i could terminate object creation in constructor if something fails? And so client that invoke constructor got information about failed obj creation?

Community
  • 1
  • 1
userbb
  • 2,148
  • 5
  • 30
  • 53

4 Answers4

12

Yes, you can: throw an exception. This is pretty much the only sensible way. By choosing the appropriate exception class (either standard or your own) and supplying a good error message etc you'll be able to tell the caller what's gone wrong.

The FAQ has more details.

NPE
  • 486,780
  • 108
  • 951
  • 1,012
  • @userbb: Note that any fully constructed members will be destructed, but the destructor of the object itself will _not_ be called. – Mooing Duck Oct 25 '11 at 18:45
5

You need to throw an exception. That is the best way to handle failing object creation.

Constructor Failures should be an Interesting read from Herb Sutter's GOTW.

Another way of doing this is that if a constructor encounters an error, set a status bit and let the user call IsOK() to see if construction actually worked.

But this is considered Obsolete.

Herb Says:

I have found the "if a constructor encounters an error, set a status bit and let the user call IsOK() to see if construction actually worked" method to be outdated, dangerous, tedious, and in no way better than throwing an exception.

Alok Save
  • 202,538
  • 53
  • 430
  • 533
2

Throwing an exception is the usual way to handle that, however, i discourage you from the pattern of throwing exceptions in constructors.

We cannot ensure that a constructor will not throw an exception but it seems to me an anti-pattern to rely on exceptions thrown by constructors. There is a subtle difference :)

I usually prefer to deal with constructors that should not fail, and move the sensible logic that can fail in an Initialize method that can return a value or throw an exception.

It is more clean and avoid you bad headache when the code gets more complicated!

This is an example of why I blieve so: http://www.cs.technion.ac.il/~imaman/programs/throwingctor.html

Another interesting post is C++ : handle resources if constructors may throw exceptions (Reference to FAQ 17.4]

Community
  • 1
  • 1
Salvatore Previti
  • 8,956
  • 31
  • 37
  • I didn't downvote but, You cannot always write a constructor that cannot fail.I guess you are hinting two towards Two Phased Construction which Symbian uses. – Alok Save Oct 25 '11 at 19:07
  • Yes you cannot always write a constructor that cannot fail but is from my point of view a good practice to avoid relying on exceptions thrown by constructors. An example is of course out of memory. – Salvatore Previti Oct 25 '11 at 19:09
  • I must admit like the two phased construction approach, not on all classes but in classes that handle with files or large amount of memory or internet connections seems to me the best choice. I didn't know Symbian used this approach, but I see it is used in a lot of languages and libraries (C++, C# and java). – Salvatore Previti Oct 25 '11 at 19:11
  • The language provides proper semantics to handle failing constructors through exceptions,I am not convinced of your belief that throwing exceptions from constructor is not a good practice,there is not enough evidence and honestly no other better options are available,which leaves exceptions to be the best choice. – Alok Save Oct 25 '11 at 19:12
  • Well i'm talking about patterns of course and not about what a language allow you to do or not... we know very well the difference. I know that there are simple situations where constructors have to throw exceptions, but I know also that it can be avoided sometime, making life easier to who write and who use some kind of classes. I saw very bad horror code in my life :( – Salvatore Previti Oct 25 '11 at 19:17
1

As aix explained, throwing from constructor is the only sensible option.

Alternatively, you can use Named Constructor Idiom (see here and here) and return null pointer if creation of new object ends up with failure.

mloskot
  • 37,086
  • 11
  • 109
  • 136
  • 1
    Agreed. In those cases where you *must* have two-phase construction, it is best to reduce the accessibility of your constructor and use a "named constructor" to create your object. The downside - most implementations rely on heap allocation (although this isn't much of a downside). – Michael Price Oct 25 '11 at 19:43