Re: Interface with implied Constructor
On Sat, 20 Jul 2013 19:46:16 +0200, Robert Klemme wrote:
On 19.07.2013 23:21, Martin Gregorie wrote:
On Fri, 19 Jul 2013 12:38:19 -0700, Gene Wirchenko wrote:
I seriously dislike init() methods, not just in Java. Particularly if
Just for the record: I am also not very fond of init methods. But I
don't condemn them either. It's not too unusual to require specific
order of method invocations in an interface. For example you need to
have invoked java.util.List.add() once before List.get(0) can return
anything meaningful.
there is no sensible un-init()'ed object for the class. I just don't
see any credible argument for them. Like Richard said, actually:
"half-baked".
I take the opposite approach to Robert over that for one reason: that
the only way to report init errors in a constructor is to throw an
Exception,
which means the instance declaration often needs to go inside a
try/catch block which can screw up scoping.
In what ways does this screw up scoping?
Just that I often find that I need access to the instance outside the try/
catch block containing the constructor call and I don't much like
initialising the pointer as null.
If init errors are possible and must be caught, I prefer to use a
constructor that can't do anything that needs an Exception to be thrown
and finish the job with an init() method that can go in the following
try/catch block along with (some of) the other method calls.
From your description I am not sure I understood the pattern you are
advertising here. Can you show this in code? The thing which irritates
me is that you want to have a "following try/catch" block. What for?
This is a result of my dislike of using Exceptions to signal anything
except a fatal error and may well be a hangover from writing a lot of C
in the past. A method that returns reference to a library class whose
constructor can throw an exception, e.g. Integer, but does not itself
return an exception requires this sort of structure:
public class Altitude
{
int alt = 0;
String error = null;
/**
* Returning a negative number indicates an invalid height.
*/
public int getHeight(String height)
{
Integer h = null;
try
{
h = new Integer(height);
if (h < 0)
error = "Below MSL";
}
catch (NumberFormatException e)
{
error = e.getMessage();
h = new Integer(-1);
}
return alt = h.intValue();
}
public boolean isValid()
{ return error === null; }
public String getError()
{ return error; }
}
This isn't a really good example because Integer provides other ways of
doing the job, but it does illustrate the sort of scoping problem I'm
talking about: that of allowing access to the Integer instance in both
parts of the try/catch block as well as from surrounding parts of the
method body.
In general I tend avoid the problem by structuring my classes so the
constructor doesn't throw exceptions, often by passing arguments that may
trigger recoverable errors as arguments to the method that uses them,
e.g. passing a file name to an 'open' method rather than consuming it in
the constructor.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |