Call by Result

Discussion in 'Java' started by Gene Wirchenko, Jun 10, 2011.

  1. Dear Java'ers:

    I wish to call by result with a method. Is it possible? If not,
    can it be easily simulated in an unnasty way?

    I am writing a simple preprocessor. I have a few spots where a
    string needs to be parsed. I want to call something like this:
    String ReturnString="";
    boolean DidItWork=GetString(ReturnString);
    if (!DidItWork)
    // too bad
    It is not acceptable to have a special String value mean failure. I
    want the method to be able to return any potential string.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 10, 2011
    #1
    1. Advertising

  2. Gene Wirchenko <> wrote:
    > I am writing a simple preprocessor. I have a few spots where a
    > string needs to be parsed. I want to call something like this:
    > String ReturnString="";
    > boolean DidItWork=GetString(ReturnString);
    > if (!DidItWork)
    > // too bad
    > 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. (Unless you consider null to
    also be a valid String-value - That typically depends on the
    context and I didn't read your wording as being explicit on that.)
    String retVal = getString();
    if (retVal == null) { /* too bad */ }
    This won't work, though, if you need to return a String both
    on failure and success.

    2) instead of the string, pass a mutable container of a string:
    String[] stringContainer = new String[1];
    boolean didItWork = getString(stringContainer);
    if (didItWork) { /* stringContainer[0] has the string */ }

    and within GetString:
    public boolean getString(String[] strCont) {
    strCont[0] = "blah"; return true;
    }

    3) encode the String: e.g.: prepend a particular text to "success"-
    strings, and a different text to "failure"-strings:

    public String getString(String[] strCont) {
    if (ok()) { return "+" + okMessage; }
    else { return "-" + errMessage; }
    }
    use:
    String retVal = getString();
    if (retVal == null || retVal.length() == 0) { /* internal error */ } else
    if ( retVal[0] == '+' ) {
    // All's well that ends well: retVal.subString(1)
    } else if ( retVal[0] == '-' ) {
    // Uh-Oh!: retVal.subString(1)
    } else { /* internal error */ }


    PS: Surely, someone will soon point out coding-conventions about
    upper-/lower-casing different kinds of identifiers. I dare to agree
    in advance. (Btw., I changed to conformant casing in my examples.)
     
    Andreas Leitgeb, Jun 10, 2011
    #2
    1. Advertising

  3. Gene Wirchenko

    Nigel Wade Guest

    On 10/06/11 08:33, Andreas Leitgeb wrote:
    > Gene Wirchenko <> wrote:
    >> I am writing a simple preprocessor. I have a few spots where a
    >> string needs to be parsed. I want to call something like this:
    >> String ReturnString="";
    >> boolean DidItWork=GetString(ReturnString);
    >> if (!DidItWork)
    >> // too bad
    >> 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".

    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...

    --
    Nigel Wade
     
    Nigel Wade, Jun 10, 2011
    #3
  4. 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.
     
    Andreas Leitgeb, Jun 10, 2011
    #4
  5. On 11-06-10 06:03 AM, Nigel Wade wrote:
    > On 10/06/11 08:33, Andreas Leitgeb wrote:
    >> Gene Wirchenko <> wrote:
    >>> I am writing a simple preprocessor. I have a few spots where a
    >>> string needs to be parsed. I want to call something like this:
    >>> String ReturnString="";
    >>> boolean DidItWork=GetString(ReturnString);
    >>> if (!DidItWork)
    >>> // too bad
    >>> 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".
    >
    > 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...
    >

    This is the kind of thing where "purists" will get a bit bloody. Not to
    teach you or any other respondent here how to suck eggs, but I'll throw
    in, for general edification of a wider audience, the information that
    we've got this problem both because Java has "pass object reference by
    value" and Strings are immutable. Hence the OP's question.

    Given that, Andreas' #2 is legit (I agree, Nigel, with your concerns
    regarding #1 and #3), and so are the two suggestions you and Patricia
    have put forth.

    I'll accept that returning an object containing both the possible
    modified String and a boolean status is OK. I don't much like it,
    however, for two reasons. It's still the use of a return value for
    operation status, and although that's defensible, there's nothing OO
    about it - it's pure imperative programming. And were we to still pursue
    that approach, unfortunately Java has no elegant means for supporting
    it, unlike Haskell Maybe or Scala Option.

    The failure of Java to cleanly support the previous approach pretty much
    argues, IMHO, for exceptions. And this is, again IMHO, quite pure. It's
    basically my business to define what I consider to be failures and
    errors. Myself I see absolutely no problem in arguing that a failure to
    work (parse) is a failure. :) It's certainly an error in the input to
    be parsed. In any case the OP would hardly be asking for an operation
    success status if it wasn't possible for the method to fail.

    Another argument for exceptions here is the OP's

    if (!DidItWork)
    // too bad

    bit. I have my doubts as to whether the OP's intended error processing
    consists just of a NOOP and a comment. Assuming that it doesn't, and one
    actually wants to do something productive in the error-handling,
    exceptions are the best way to do it.

    AHS
     
    Arved Sandstrom, Jun 10, 2011
    #5
  6. Gene Wirchenko

    Eric Sosman Guest

    On 6/10/2011 2:03 AM, Gene Wirchenko wrote:
    > Dear Java'ers:
    >
    > I wish to call by result with a method. Is it possible? If not,
    > can it be easily simulated in an unnasty way?
    >
    > I am writing a simple preprocessor. I have a few spots where a
    > string needs to be parsed. I want to call something like this:
    > String ReturnString="";
    > boolean DidItWork=GetString(ReturnString);
    > if (!DidItWork)
    > // too bad
    > 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 are lots of ways to do what I think you want (the phrase
    "call by result" is new to me). One is

    class ResultHolder {
    String returnString;
    // ... other stuff, if desired
    };

    ResultHolder result = new ResultHolder();
    result.returnString = ""; // if desired
    boolean didItWork = getString(result);
    if (didItWork)
    System.out.println("Result is " + result.returnString);
    else
    System.err.println("Woe is me!");

    The same thing, really, in a quick-and-dirty form:

    String[] result = new String[1];
    boolean didItWork = getString(result);
    if (didItWork)
    System.out.println("Result is " + result[0]);
    else
    System.err.println("Woe is me!");

    Still another variation is to put the String and the boolean
    in the same holder class (I'd be tempted to rename the boolean to
    something like isValid).

    Of course, there's a completely different approach:

    try {
    String result = getString();
    System.out.println("Result is " + result);
    } catch (ItsNoGoodException ex) {
    System.err.println("Woe is me!");
    }

    .... and I'm sure there are possibilities beyond these.

    --
    Eric Sosman
    d
     
    Eric Sosman, Jun 10, 2011
    #6
  7. Arved Sandstrom <> wrote:
    > I'll accept that returning an object containing both the possible
    > modified String and a boolean status is OK. I don't much like it,


    Why would such a returned object contain a possibly *modified* String?
    It would expectably contain whatever String the method getString wants
    the caller to see. It doesn't get one from outside in this case (as
    opposed to my #2 case), so there's nothing to "modify".

    > however, for two reasons. It's still the use of a return value for
    > operation status, and although that's defensible, there's nothing OO
    > about it - it's pure imperative programming. And were we to still pursue
    > that approach, unfortunately Java has no elegant means for supporting
    > it, unlike Haskell Maybe or Scala Option.


    Not sure, what feature you're principially talking of. Is it some kind of
    syntactic sugar to further simplify code like this:

    BoolStr bs = getString();
    boolean b=bs.bool; String s=bs.str;

    ?
    (just curious)
     
    Andreas Leitgeb, Jun 10, 2011
    #7
  8. Gene Wirchenko

    Silvio Guest

    On 06/10/2011 08:03 AM, Gene Wirchenko wrote:
    > Dear Java'ers:
    >
    > I wish to call by result with a method. Is it possible? If not,
    > can it be easily simulated in an unnasty way?
    >
    > I am writing a simple preprocessor. I have a few spots where a
    > string needs to be parsed. I want to call something like this:
    > String ReturnString="";
    > boolean DidItWork=GetString(ReturnString);
    > if (!DidItWork)
    > // too bad
    > It is not acceptable to have a special String value mean failure. I
    > want the method to be able to return any potential string.
    >
    > Sincerely,
    >
    > Gene Wirchenko


    This is a perfect case for the Scala Option and the Haskell Maybe construct.

    You could Google for them and create such a beast in Java yourself. It
    would be a good replacement for most places where you now use null...

    Silvio
     
    Silvio, Jun 10, 2011
    #8
  9. Gene Wirchenko

    Stefan Ram Guest

    Gene Wirchenko <> writes:
    >I wish to call by result with a method.


    I am surprised about all the answers, whose authors seems
    to have understood what Gene wanted to convey with this.

    I never have heard »call by result«.

    But I was able to look it up in an online encyclopedia:

    »When the reference is passed to the callee
    uninitialized, this evaluation strategy may
    be called "call by result".«

    http://en.wikipedia.org/wiki/Evaluation_strategy

    Did you all knew this before you answered? The reference
    has to be /uninitialized/ for an evaluation strategy to be
    called "call by result"!

    >String ReturnString="";
    >boolean DidItWork=GetString(ReturnString);


    But in Java we cannot pass uninitialized references!
    Especially, in this case, the reference is not uninitialized.
    So how could a call by result be possible in Java without
    the means to pass uninitialized references?

    Also, »call by result« is a special case of
    »call by copy-restore«, (see the above URI),
    which I do not understand. But I am not sure whether even
    this »call by copy-restore« is possible in Java, since its
    descriptions refers to acts of leaving some results
    undefined (which is possible in Perl, but not in Java).
     
    Stefan Ram, Jun 10, 2011
    #9
  10. Stefan Ram <-berlin.de> wrote:
    > Gene Wirchenko <> writes:
    >> I wish to call by result with a method.

    > I am surprised about all the answers, whose authors seems
    > to have understood what Gene wanted to convey with this.


    Ok, I admit, I was a bit confused, too, at first, but
    the example was good at clarifying what the OP meant.
     
    Andreas Leitgeb, Jun 10, 2011
    #10
  11. Gene Wirchenko

    Stefan Ram Guest

    Peter Duniho <> writes:
    >That is, it seems more likely that what the OP cares about is
    >the "modify the argument, return a boolean" aspect more than
    >he cares about the "was the argument initialized" aspect.


    Ok, the OP contained:

    >>>String ReturnString="";
    >>>boolean DidItWork=GetString(ReturnString);
    >>>if (!DidItWork)


    For my taste, the object-oriented way to do this is:

    final Getter getter = new Getter();
    getter.get();
    if( getter.isValid() )result = getter.value(); else ...

    , while the Java way to do this is

    try{ s = getString(); }
    catch( final Exception exception )...

    . The OP used upper-case names of variables and methods,
    so he might be a beginner in Java, in which case it might be
    more appropriate for him to learn how things are natively
    done in Java than to learn how to emulate features of other
    languages (such as call by result) in Java.
     
    Stefan Ram, Jun 10, 2011
    #11
  12. Gene Wirchenko

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >»When the reference is passed to the callee
    >uninitialized, this evaluation strategy may
    >be called "call by result".«
    >http://en.wikipedia.org/wiki/Evaluation_strategy


    Ok, the Wikipedia possibly might be wrong or misleading here.
    What it means according to another source is that

    - for each »out parameter«, uninitialized space is
    reserved in the activation record /of the callee/,

    - then the callee writes to that space, and finally,

    - the value in that space is copied to the corresponding
    »out argument« variable.

    However, it might be a further optimization, that the caller
    also is allowed to pass an uninitialized »out variable«.
     
    Stefan Ram, Jun 10, 2011
    #12
  13. Gene Wirchenko

    markspace Guest

    On 6/9/2011 11:03 PM, Gene Wirchenko wrote:
    > Dear Java'ers:
    >
    > I wish to call by result with a method. Is it possible? If not,
    > can it be easily simulated in an unnasty way?
    >
    > I am writing a simple preprocessor. I have a few spots where a
    > string needs to be parsed. I want to call something like this:
    > String ReturnString="";
    > boolean DidItWork=GetString(ReturnString);
    > if (!DidItWork)
    > // too bad
    > It is not acceptable to have a special String value mean failure. I
    > want the method to be able to return any potential string.



    I'm kind of surprised by all the answers here also. I'm glad Stefan
    pointed out the definition of "call by result," which I also did not know.

    However call-by-result is just a use case of pass-by-reference, so why
    not use that? In Java the standard quicky semantic is to use an array.

    String[] returnString = new String[1]; // just 1 return string
    boolean didItWork = GetString( returnString );
    if( didItWork ) {
    String result = returnString[0];
    .... process result here
    } else {
    .... too bad
    }

    returnString is just a holder, as was mentioned earlier, but temporary
    arrays are often used for pass by reference in Java (which only has pass
    by value), so any programmer is likely to grasp what is going on here
    quickly.
     
    markspace, Jun 10, 2011
    #13
  14. On 10/06/2011 07:03, Gene Wirchenko wrote:
    > Dear Java'ers:
    >
    > I wish to call by result with a method. Is it possible?


    No, strings are immutable, so GetString() cannot alter the value of
    ReturnString.


    > If not, can it be easily simulated in an unnasty way?


    I believe it is better to use a Java pattern which other Java
    programmers will be familiar with.


    >
    > I am writing a simple preprocessor. I have a few spots where a
    > string needs to be parsed. I want to call something like this:
    > String ReturnString="";
    > boolean DidItWork=GetString(ReturnString);
    > if (!DidItWork)
    > // too bad
    > It is not acceptable to have a special String value mean failure. I
    > want the method to be able to return any potential string.
    >


    I think Stephan Ram's answer is roughly what I would do.

    String returnString;
    Thagomizor thangomizor = new Thagomizor();
    thangomizor.thangomize();
    if (!thangomizor.didItWork()) {
    throw new TooBadException();
    } else {
    returnString = thangomizor.getString();
    }



    --
    RGB
     
    RedGrittyBrick, Jun 10, 2011
    #14
  15. On Fri, 10 Jun 2011 17:01:36 +0100, RedGrittyBrick wrote:

    > I think Stephan Ram's answer is roughly what I would do.
    >
    > String returnString;
    > Thagomizor thangomizor = new Thagomizor(); thangomizor.thangomize();
    > if (!thangomizor.didItWork()) {
    > throw new TooBadException();
    > } else {
    > returnString = thangomizor.getString();
    > }


    Likewise, this is my usual style too, though its quite possibly a carry-
    over from the way I write C.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Jun 10, 2011
    #15
  16. On 10 Jun 2011 07:33:12 GMT, Andreas Leitgeb
    <> wrote:

    >Gene Wirchenko <> wrote:
    >> I am writing a simple preprocessor. I have a few spots where a
    >> string needs to be parsed. I want to call something like this:
    >> String ReturnString="";
    >> boolean DidItWork=GetString(ReturnString);
    >> if (!DidItWork)
    >> // too bad
    >> 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:


    >2) instead of the string, pass a mutable container of a string:
    > String[] stringContainer = new String[1];
    > boolean didItWork = getString(stringContainer);
    > if (didItWork) { /* stringContainer[0] has the string */ }
    >
    > and within GetString:
    > public boolean getString(String[] strCont) {
    > strCont[0] = "blah"; return true;
    > }


    This is a kludge but fairly simple. I did a bit more looking and
    found
    http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html
    where a simple class is created. I ended up with

    ***** Start of Code *****
    // Parameters.java
    // Experimenting with Parameters
    // Last Modification: 2011-06-10



    class StringValue
    {
    String Value;
    }

    class IntValue
    {
    int Value;
    }



    public class Parameters
    {

    public static void main
    (
    String[] args
    )

    {
    IntValue a=new IntValue();
    IntValue b=new IntValue();
    StringValue RetVal=new StringValue();

    a.Value=1;
    b.Value=2;

    System.out.println(
    "a="+a.Value+", b="+b.Value+", RetVal="+RetVal.Value);

    ChangeValues(a,b,RetVal);

    System.out.println(
    "a="+a.Value+", b="+b.Value+", RetVal="+RetVal.Value);
    }

    public static void ChangeValues
    (
    IntValue First,
    IntValue Second,
    StringValue ReturnValue
    )

    {
    First.Value*=2;
    Second.Value++;
    ReturnValue.Value="change";
    }

    }
    ***** End of Code *****

    [snip]


    >PS: Surely, someone will soon point out coding-conventions about
    > upper-/lower-casing different kinds of identifiers. I dare to agree
    > in advance. (Btw., I changed to conformant casing in my examples.)


    I have used a number of languages. One of the things that I
    dislike about Java is the small letter first style. It is
    particularly bothersome, because my variable naming convention often
    has HN-like prefixes. When I use a prefix, the main part of the name
    is initial-capitalised; prefixes are not capitalised. For example,
    "fhIn" is file handle for In.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 10, 2011
    #16
  17. On Fri, 10 Jun 2011 08:23:17 -0300, Arved Sandstrom
    <> wrote:

    [snip]

    >This is the kind of thing where "purists" will get a bit bloody. Not to


    Let them scream. I have other comments elsethread. In short, if
    your favourite way of doing things causes me a bunch of extra work to
    use, I am liable to not use it.

    >teach you or any other respondent here how to suck eggs, but I'll throw
    >in, for general edification of a wider audience, the information that
    >we've got this problem both because Java has "pass object reference by
    >value" and Strings are immutable. Hence the OP's question.


    Nope. I simply want to call by result.

    >Given that, Andreas' #2 is legit (I agree, Nigel, with your concerns
    >regarding #1 and #3), and so are the two suggestions you and Patricia
    >have put forth.


    I based my answer on #2.

    >I'll accept that returning an object containing both the possible
    >modified String and a boolean status is OK. I don't much like it,
    >however, for two reasons. It's still the use of a return value for
    >operation status, and although that's defensible, there's nothing OO
    >about it - it's pure imperative programming. And were we to still pursue
    >that approach, unfortunately Java has no elegant means for supporting
    >it, unlike Haskell Maybe or Scala Option.


    Well, imperative programming does exist, and I use it.

    >The failure of Java to cleanly support the previous approach pretty much
    >argues, IMHO, for exceptions. And this is, again IMHO, quite pure. It's


    Nope. Too complicated.

    >basically my business to define what I consider to be failures and
    >errors. Myself I see absolutely no problem in arguing that a failure to
    >work (parse) is a failure. :) It's certainly an error in the input to
    >be parsed. In any case the OP would hardly be asking for an operation
    >success status if it wasn't possible for the method to fail.
    >
    >Another argument for exceptions here is the OP's
    >
    >if (!DidItWork)
    > // too bad
    >
    >bit. I have my doubts as to whether the OP's intended error processing
    >consists just of a NOOP and a comment. Assuming that it doesn't, and one
    >actually wants to do something productive in the error-handling,
    >exceptions are the best way to do it.


    Get real! It is common in examples to have a comment indicating
    what would be done when said code is not particularly relevant to the
    example.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 10, 2011
    #17
  18. On 11-06-10 10:12 AM, Andreas Leitgeb wrote:
    > Arved Sandstrom <> wrote:
    >> I'll accept that returning an object containing both the possible
    >> modified String and a boolean status is OK. I don't much like it,

    >
    > Why would such a returned object contain a possibly *modified* String?
    > It would expectably contain whatever String the method getString wants
    > the caller to see. It doesn't get one from outside in this case (as
    > opposed to my #2 case), so there's nothing to "modify".


    Sorry, my brain disconnected from my fingertips for a few seconds there.
    Not "possible modified" String, but just result String. You're quite right.

    >> however, for two reasons. It's still the use of a return value for
    >> operation status, and although that's defensible, there's nothing OO
    >> about it - it's pure imperative programming. And were we to still pursue
    >> that approach, unfortunately Java has no elegant means for supporting
    >> it, unlike Haskell Maybe or Scala Option.

    >
    > Not sure, what feature you're principially talking of. Is it some kind of
    > syntactic sugar to further simplify code like this:
    >
    > BoolStr bs = getString();
    > boolean b=bs.bool; String s=bs.str;
    >
    > ?
    > (just curious)


    Maybe and Option are datatypes that allow you to return either the
    requested value or a value that represents a failure of the computation.
    This is conceptually different from having a special value, because in
    the case of Maybe or Option, if the function/method succeeds, *every*
    possible value of the underlying datatype (String or Integer or
    whatever) is still a legal successful value. In effect Maybe and Option
    are wrapper types just like BoolStr in your example; it's simply that
    Scala and Haskell have better language support for dealing with
    datatypes of that sort.

    Like I said, in Java the "BoolStr" approach wouldn't be *my* preference
    - I like exceptions here. But I wouldn't hold my nose if someone decided
    to use "BoolStr".

    AHS
     
    Arved Sandstrom, Jun 10, 2011
    #18
  19. On Fri, 10 Jun 2011 09:30:58 -0700, Patricia Shanahan <>
    wrote:

    >On 6/10/2011 2:03 AM, Nigel Wade wrote:
    >...
    >> 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...


    >My view of this is that a method should not be called "getString", or
    >any variation on that theme, unless its primary purpose is to get a
    >string. In that case, it should return the string it gets. Any failure
    >to get the string is an exception relative to its purpose.


    Its primary purpose is to get a string. Where its result is
    returned is not so important. Call by result is compact.

    >Even when programming in C, I regarded the tendency to return a
    >success/fail flag and treat the main purpose of the function as a side
    >effect as an unfortunate but necessary ugliness. In Java, I regard it as
    >pure ugliness, with no justifying necessity.


    It is interesting that the so-called ugliness is much shorter
    than the try-catch ugliness. The added verbosity of try-catch does
    not add anything to the code.

    I think that using exceptions can bloat one's code all to easily.
    I like my code's flow of control to read as a story. If there are too
    many interruptions, it is difficult to see that story.

    >Some people seem to confuse making something an exception in a
    >particular interface with regarding it as a whole program failure. That
    >makes no sense to me. If there is to be any hope of code reuse, method
    >interfaces must be designed based solely on the method's intended
    >function, not the overall program design.


    The method's intended function is as a subroutine in imperative
    code.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 10, 2011
    #19
  20. On Fri, 10 Jun 2011 01:30:03 -0700, Patricia Shanahan <>
    wrote:

    [snip]

    >Exceptions provide an alternative. Rather than returning a didItWork
    >boolean, return the String if it did work, and throw an exception if it
    >did not work.


    if-else does so, too, and is more compact.

    >In addition to allowing the method to return its primary result, it also
    >allows for passing back more information in the case of failure, which
    >can lead to better reporting.


    So does call-by-result, and in less space.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 10, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. J.Ram
    Replies:
    7
    Views:
    680
  2. Pavel
    Replies:
    7
    Views:
    561
    Pavel
    Sep 19, 2010
  3. Lakshmi Sreekanth

    i = 10; result = ++i - --i; How result become ZERO

    Lakshmi Sreekanth, Sep 21, 2010, in forum: C Programming
    Replies:
    52
    Views:
    1,237
    Nick Keighley
    Sep 23, 2010
  4. Mr. Buffoon
    Replies:
    4
    Views:
    352
    Eric Sosman
    Sep 23, 2010
  5. Michael Tan
    Replies:
    32
    Views:
    1,075
    Ara.T.Howard
    Jul 21, 2005
Loading...

Share This Page