I would tend to avoid doing lots of blocking IO inside constructors.

You may want to consider writing a helper class that will allow you to
interact with your users. A class with static helper methods will do
this quite nicely so you have something like...

int value = Console.getIntInput("Please enter your age:");

The getIntInput method would print the argument to the screen, and
handle input data (including the parseInt call and validation). Then
your code would look more like this...

int int1 = getIntInput("Please provide a number:");
int int2 = getIntInput("Please provide another number:");
String string1 = getStringInput("What is your name:");
double double1 = getDoubleInput("What is your bank balance:");

ProblemSpec spec = new ProblemSpec(int1, int2, string1, double1);
long result = spec.calculateResult();

Something like this would be cleaner in my opinion.

Constructors should only contain code that is safe.  If you have
something that can throw an exception, put tn in a method so you can
properly handle the error, or have the calling object handle any
exceptions that are thrown.  Client code shouldn't have to worry about
an exception being thrown when it creates a "NEW" instance of an
object. i.e. bad:

try{
   Object a = new Object()
}catch(Exception e)
{
   ....
}

Obviously this could be avoided by catching all throwables in the
constructor, but it is not a good programming paradigm to have business
logic contained in a constructor.

Ryan

As another reply said: avoid doing any 'real' work in the constructor.
Two good reasons for doing this:

1) The order of superclass setup (e.g. static versus none static member
var instantiation) can lead to confusion and head banging. Keep as
little in the constructor as possible.

2) Objects are nouns (things), not verbs (actions)! Therefore it can be
surpising when constructor do too much. 'new' should mean just that -
make a new somehting - but not actually do anything yet.

lex