Chris Riesbeck wrote :

Just make sure that the create() method does a sanity check to ensure
that ALL the required information has been set. So someone does not
simply call:

Project project = new Project.Builder().create();

Lew wrote:

Your reasoning is quite sound.  I'd phrase the principles involved a little
differently, but I'd bet I'd come up with the same conclusions.

While I said that constructors can legitimately throw exceptions, I didn't say
they should, necessarily.  Constructors should throw exceptions only if the in
the logic of construction it makes sense.  For example, in your GetOpt class
I'd consider throwing an exception if args[] were null.  That way the client
code finds out at the point of error that there was a problem.  Throwing an
NPE in the process() method (or whatever you call it) is useful, but could
happen distant from the point of error, passing null to the constructor.

Then I'd likely reject that idea and treat null args the same as empty args,
i.e., no options.

But that's the kind of reasoning that might lead me to throw an exception from
a constructor.  I admit I would resist it until compelled.  What would compel
is a condition that must halt the program, like a Data Access Object (DAO) not
finding its datastore driver.

As for not processing args in the constructor, that's a different principle
for me.  Constructors are for construction, period.  Processing the args is
not part of constructing the object; passing them into an instance variable
is.  Doing too much in a constructor is a mistake in its own right, and leads
to various kinds of trouble.

We converge in that the less one does in a constructor, the less excuse one
has to throw exceptions there.  With the constructor's purpose clearly
understood and constrained, the kinds of things that can throw exceptions in
it tend to be excluded.

One particular instance I can think of is to throw an
IllegalArgumentException if arguments are passed that just don't make
any sense.