Handling exceptions

Discussion in 'Java' started by ahjiang@gmail.com, Jan 21, 2007.

  1. Guest

    Lets say i have this method

    int foo() {
    try {
    do something;
    return SUCCESS;
    }catch(Exception e){
    print e;
    }finally{
    return FAILURE;
    }
    }

    I understand that failure will always be returned because of the
    finally clause.
    What is the best practice to return a value if success or failure.
    Or should the exception be propagated to the calling method?

    Appreciate any advice
     
    , Jan 21, 2007
    #1
    1. Advertising

  2. hiwa Guest

    wrote:
    > Lets say i have this method
    >
    > int foo() {
    > try {
    > do something;
    > return SUCCESS;
    > }catch(Exception e){
    > print e;
    > }finally{
    > return FAILURE;
    > }
    > }
    >
    > I understand that failure will always be returned because of the
    > finally clause.
    > What is the best practice to return a value if success or failure.
    > Or should the exception be propagated to the calling method?
    >
    > Appreciate any advice

    return FAILURE; should be in the catch clause.
    Your finally clause is not necessary.
     
    hiwa, Jan 21, 2007
    #2
    1. Advertising

  3. hiwa wrote:
    > wrote:
    >> Lets say i have this method
    >>
    >> int foo() {
    >> try {
    >> do something;
    >> return SUCCESS;
    >> }catch(Exception e){
    >> print e;
    >> }finally{
    >> return FAILURE;
    >> }
    >> }
    >>
    >> I understand that failure will always be returned because of the
    >> finally clause.
    >> What is the best practice to return a value if success or failure.
    >> Or should the exception be propagated to the calling method?
    >>
    >> Appreciate any advice

    > return FAILURE; should be in the catch clause.
    > Your finally clause is not necessary.
    >


    Or with only one return statement per method (there is only one exit
    point - you cannor overlook it when making modifications):

    int foo() {
    int retval = SUCCESS;
    try {
    do something;
    }catch(Exception e){
    print e;
    retval = FAUILURE;
    }
    return retval;
    }
     
    Helmut Leininger, Jan 21, 2007
    #3
  4. Tom Hawtin Guest

    wrote:
    >
    > int foo() {
    > try {
    > do something;
    > return SUCCESS;
    > }catch(Exception e){
    > print e;
    > }finally{
    > return FAILURE;
    > }
    > }
    >
    > I understand that failure will always be returned because of the
    > finally clause.
    > What is the best practice to return a value if success or failure.
    > Or should the exception be propagated to the calling method?


    Use exceptions for fault reporting. Return values are often difficult
    for client code and have a long history of being ignored (for instance
    in a live system the cd command failed one day in `cd xyz ; rm -rf *`).
    Also you wont be able to use a return value (sensibly) if it is already
    used to signal faults.

    If you must return an error status, write it something like:

    BarErrorStatus foo() {
    try {
    do something;
    return BarErrorStatus.SUCCESS;
    } catch (SomeException exc) {
    // [ Or something at least a little descriptve. ]
    return BarErrorStatus.FAILURE;
    }
    }

    If you use a variable for status for some reason (for instance for use
    in code following the try/catch/finally), if you leave it unassigned
    until as late as possible, you can use the definite
    assignment/unassignment rules to catch errors:


    void foo() {
    BarErrorStatus errorStatus;
    try {
    do something;
    errorStatus = BarErrorStatus.SUCCESS;
    } catch (SomeOtherException exc) {
    exc.printStackTrace(); <-- Compiler error.
    } catch (SomeException exc) {
    // [ Or something at least a little descriptve. ]
    errorStatus = BarErrorStatus.FAILURE;
    }
    if (errorStatus == BarErrorStatus.SUCCESS) {
    blah;
    }
    }


    It is (or should be) rare to catch
    Exception/Throwable/Error/RuntimeException.

    Sometimes, you do need a status flag:

    Connection openConnection() throws ConnectionException {
    boolean succeeded = false;
    Connection raw = new RawConnection(someField);
    try {
    Connection buffered = new BufferedConnection(raw);
    succeeded = true;
    return buffered;
    } finally {
    if (!succeeded) {
    raw.close();
    }
    }
    }

    (Although most people seem to like to leak resources instead...)

    Tom Hawtin
     
    Tom Hawtin, Jan 21, 2007
    #4
  5. Adam Maass Guest

    <> wrote :
    > Lets say i have this method
    >
    > int foo() {
    > try {
    > do something;
    > return SUCCESS;
    > }catch(Exception e){
    > print e;
    > }finally{
    > return FAILURE;
    > }
    > }
    >
    > I understand that failure will always be returned because of the
    > finally clause.
    > What is the best practice to return a value if success or failure.
    > Or should the exception be propagated to the calling method?
    >


    Generally speaking, my preference would be to propagate some sort of
    exception rather than return a success code.

    Your method would then look something like this:

    void foo() throws FooException {
    try {
    do something;
    } catch (SomethingException e) {
    throw new FooException(e);
    }
    }


    The caller of the method need not write code like this:

    if(foo() != SUCCESS){
    recover
    }
    more stuff

    (This hides the fact that foo() is being called inside a conditional, and
    places the recovery code -- which isn't necessarily the main flow of the
    program -- right next to the callpoint.)


    But instead the calling code looks more like:

    try{
    foo();
    more stuff
    } catch (FooException e) {
    recover
    }

    (This makes the call to foo() about as explicit as can be, and the recovery
    code is nicely isolated, away from the main flow of the program.)



    OK, now for quibbling:

    I generally like the exceptions approach for those situations that are truly
    exceptional -- making it worth your while to abruptly terminate your caller
    and force it to do something it wouldn't usually. If instead, there are a
    variety of situations that can normally be expected to happen, and your
    caller should be expected to know about and handle them all, then returning
    some sort of status code is just fine in my book. What's more appropriate
    depends on the situation and is something of a judgment call in any case.

    What really gets my goat is "catch Throwable" or its only slightly less
    pernicious twin, "catch Exception". These are too general and should almost
    never be written.

    -- Adam Maass
     
    Adam Maass, Jan 22, 2007
    #5
    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. Raterus
    Replies:
    6
    Views:
    579
    Raterus
    Aug 24, 2004
  2. Ahmed Moustafa
    Replies:
    5
    Views:
    30,045
    Chris Smith
    Jul 14, 2004
  3. Paul Miller
    Replies:
    3
    Views:
    1,026
    Alex Martelli
    Nov 12, 2003
  4. Replies:
    3
    Views:
    617
    Sherm Pendley
    Apr 16, 2007
  5. Lie
    Replies:
    3
    Views:
    637
Loading...

Share This Page