Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Interface with implied Constructor Date: Sat, 20 Jul 2013 19:46:16 +0200 Lines: 39 Message-ID: References: <925adeb1-65b5-4a50-86a8-4f04784f8da0@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net KRgRvhPsYxzm/EIdw9DI2Ay1YBNchO5K4azLgBLum2T9gn8bE= Cancel-Lock: sha1:ApK5NF7F5VQ1KUQW7zHKSjM8FuA= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: X-Antivirus: avast! (VPS 130720-0, 20.07.2013), Outbound message X-Antivirus-Status: Clean Xref: csiph.com comp.lang.java.programmer:24776 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? > 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? Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/