Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder4.news.weretis.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.lang.java.programmer From: Andreas Leitgeb Subject: Re: Call by Result References: <95e4uuF3cvU1@mid.individual.net> Reply-To: avl@logic.at User-Agent: slrn/pre0.9.9-111 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: 10 Jun 2011 09:47:23 GMT Lines: 38 NNTP-Posting-Host: gamma.logic.tuwien.ac.at X-Trace: 1307699243 tunews.univie.ac.at 73248 128.130.175.3 X-Complaints-To: abuse@tuwien.ac.at Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5173 Nigel Wade wrote: > On 10/06/11 08:33, Andreas Leitgeb wrote: >> Gene Wirchenko wrote: >>> It is not acceptable to have a special String value mean failure. I >>> want the method to be able to return any potential string. >> There's three basic ways to do it: >> 1) Return null to indicate failure. >> 2) instead of the string, pass a mutable container of a string: >> 3) encode the String: e.g.: prepend a particular text to "success"- > Are 1) and 3) not precluded by the proviso "It is not acceptable to have > a special String value mean failure". It is conceivable that "1)" might be, but (in my understanding) not implied. It boils down to whether one considers null to be a String value. If you think "of course", then so be it. I don't really care. "3)" is rather not, because it is just a different way of implementing your "4)" below. (Although it might take some more fuss to also encode possible nulls for success and failure into the return string, if at all needed.) Both the boolean and the original string value can be safely extracted from the encoded string. I'm speaking of "String values" here, such as identified by .equals(), not of String instances, though. So, if the latter has to be preserved, too, then "3)" would indeed be ruled out. > A fourth way would be to return a class/object containing both the > boolean and the String. To me, this would be the natural OO way of > returning more information than a primitive type. > > And a 5th way could be to return the String and throw an Exception if it > did not work. Some purists may argue that failure to work is not > strictly an exception, but if it gets the job done... "4)" and "5)" are both very good ideas, both nicer/cleaner than mine, and I'm a bit embarrassed for not having thought of them, myself. (Well, at least, mine are a bit shorter to implement ;-) "5)" has also been suggested by Patricia.