A lot of things can be partitioned into do-actions and undo-actions.

E.g. resource allocation and deallocation.

According to this philosophy you should perform do-actions in a constructor and the matching un-do action in a destructor.

Throw an object containing rich error information in case of the do-action fails.

The win32 library can be nicely wrapped into such classes.

When you're going this way you can chain such objects into base class and member class relationships.

You only have to write code for the successful case.

The compiler will generate code, to deal with the case any of the base or member object fails to initialize.

Try to allocate only a single resource in a single constructor.

Otherwise you will have to deal with failure by yourself instead of leaving this up to the compiler.

Another good philosophy (which may be derived from RAII) is to design classes in such a way,

that all public methods are always callable as soon as such an object exists.

Or in other words: It is bad philosophy to design classes in such a way, that certain methods must be called in a particular order.

Following this philosophy leads to code which avoids null-pointer access.