Constructors should be simple, predictable, and never fail.

Simple

Keep your constructors simple in the sense that:

• Few parameters. Ever hear that a “function should do one thing and do it
  well”? It applies to constructors, too.
• Few overrides. Don’t try to get around the previous dictum by having a bunch
  of overrides on the constructors. It’s confusing for someone to understand
  the initial state if there are a bunch of initial states.
• Leave the work to public methods. If you think everything the constructor
  needs to be able to provide the ultimate configuration for an object you are
  trying to control (constrict) some developers too much.

Predictable

We write code like:

int  days = 13;

and don’t expect initialization to be doing very much work. Developers are used to that. Same with:

MyType val = new MyType(arg1, arg2);

should just be doing initialization comparable to assigning that integer. If
you want to have the constructor do a bunch of database work, factor that out
into a separate method:

val.LoadDB();

Many times people with constructor fever think have an underlying mindset that
thinks an object should be completely initialized and everything handled at the
constructor level. If you make every member function “const” then I’d believe
you. Otherwise, it’s just being a control freak.

Never fail

A constructor shouldn’t fail except under the most exceptional of circumstances
(out of memory). Examples of things that are not exceptional: a file doesn’t
exist, a network connection doesn’t succeed, input is poorly formatted, etc.