compiler warning

Discussion in 'Java' started by dennishancy@eaton.com, Aug 4, 2005.

  1. Guest

    When compiling my application, I am getting this warning msg:

    ---------
    warning: finally clause cannot complete normally
    ---------

    I get this warning once for every finally clause in my code.

    What does this mean? What can I do to fix this?

    Thanks in advance.


    Dennis Hancy
    Eaton Corporation
    Cleveland, OH
    , Aug 4, 2005
    #1
    1. Advertising

  2. John Currier Guest

    John Currier, Aug 4, 2005
    #2
    1. Advertising

  3. Chris Smith Guest

    <> wrote:
    > When compiling my application, I am getting this warning msg:
    >
    > ---------
    > warning: finally clause cannot complete normally
    > ---------
    >
    > I get this warning once for every finally clause in my code.
    >
    > What does this mean? What can I do to fix this?


    You're doing something that you shouldn't do in your finally clauses.
    If you post an example of code that does this, we could offer more help.

    "Completing normally" is a technical term in the Java Language
    Specification. It means finishing a block of code because you run into
    the end of it and have no more code to run. A block of code can also
    complete ABNORMALLY by:

    1. Encountering a return, break, or continue statement.
    2. Throwing an exception that isn't handled within that block.

    Finally blocks should generally be able to complete normally. Although
    the language specification doesn't require it, it just makes sense.
    Hence the warning. As an example, you might write this:

    try
    {
    doSomeIO();
    }
    finally
    {
    cleanup();
    return;
    }

    The problem is that the return statement prevents the finally block from
    completing normally. If doSomeIO() throws an exception, that exception
    will be completely lost without a trace. That's because when a finally
    block completes abnormally, any exceptions are lost and the program
    continues in whatever way the finally block told it to. In this case,
    that means returning from a method, NOT throwing whatever exception got
    you to the finally block in the first place.

    There is some debate about whether a finally block should EVER complete
    abnormally in case of a second error, for example. However, ever
    finally block should complete normally at least as the main case,
    possibly with exceptions being thrown in the oddball cases.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Aug 4, 2005
    #3
  4. Harry Bosch Guest

    You must be using an older compiler (1.3.x?). The newer compilers
    enforce the spec and do not allow return statements within a finally
    block(thank god) AFAIK.
    Harry Bosch, Aug 5, 2005
    #4
  5. Harry Bosch wrote:
    > You must be using an older compiler (1.3.x?). The newer compilers
    > enforce the spec and do not allow return statements within a finally
    > block(thank god) AFAIK.


    class F { void f() {try { } finally { return; }}}

    Works for me.

    However if I add -Xlint:finally (from 1.5 onwards), I do get a warning.

    C# doesn't allow return in finally.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Aug 5, 2005
    #5
  6. Harry Bosch wrote:
    > You must be using an older compiler (1.3.x?). The newer compilers
    > enforce the spec and do not allow return statements within a finally
    > block(thank god) AFAIK.
    >


    Which specification prohibits return statements within a finally block?
    Can you give a reference?

    Patricia
    Patricia Shanahan, Aug 5, 2005
    #6
  7. Guest

    My finally clauses are pretty simplistic. They look like this:

    finally {
    return(vRet);
    }

    where vRet is declared as follows.

    Vector vRet = new Vector();


    Thanks.


    Dennis
    , Aug 5, 2005
    #7
  8. jan V Guest

    > My finally clauses are pretty simplistic. They look like this:
    >
    > finally {
    > return(vRet);
    > }


    But that makes no sense at all... ! Can you explain what you're trying to
    achieve by this?

    (and by the way, you don't need to add parentheses for a return... you make
    it look like it's a method call when it's not)
    jan V, Aug 5, 2005
    #8
  9. wrote:
    > My finally clauses are pretty simplistic. They look like this:
    >
    > finally {
    > return(vRet);
    > }
    >
    > where vRet is declared as follows.
    >
    > Vector vRet = new Vector();
    >
    >
    > Thanks.
    >
    >
    > Dennis
    >


    Here's the issue. Without seeing the rest of your code, I don't know
    whether you have already taking this into account and coped with it.

    When a finally clause completes abruptly, completes by throwing
    something or returning, the whole try-catch-finally completes abruptly
    for the same reason, losing the original completion condition.

    Suppose something went really, really bad during the try clause, and an
    Error was thrown. Unless you are catching and logging that Error, it
    will be completely lost when the finally returns.

    Patricia
    Patricia Shanahan, Aug 5, 2005
    #9
  10. Patricia Shanahan <> writes:

    > Which specification prohibits return statements within a finally
    > block? Can you give a reference?


    A "return" counts as abrubt completion - not normal completion (JLS
    §14.1). But I cannot see anywhere (§14.20.2) that prohibits a finally
    block from completing abruptly. However, when it does, any Throwable
    that may have been thrown, or any return value from the try block, is
    lost.

    E.g. the following method will return 16:

    public static int foo() {
    try {
    return 42;
    }
    finally {
    return 16;
    }
    }

    I'd say it's bad practice to have the finally block complete abruptly,
    but it's not against the spec.
    Tor Iver Wilhelmsen, Aug 6, 2005
    #10
  11. Tor Iver Wilhelmsen wrote:
    >
    > I'd say it's bad practice to have the finally block complete abruptly,
    > but it's not against the spec.


    I'm happy with finally blocks throwing exceptions. If the try threw then
    one exception must be dropped. If there was a failure in the finally
    block then it would be at least as important as the exception it blocks.

    Sometimes it can be useful to structure code as:

    boolean success = false;
    try {
    ...
    success = true;
    } finally {
    if (!success) {
    ...dispose of resources...
    }
    }

    I guess you could return if success was true in that finally block.
    Don't know why you'd want to though.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Aug 6, 2005
    #11
  12. Patricia Shanahan coughed up:
    > Harry Bosch wrote:
    >> You must be using an older compiler (1.3.x?). The newer compilers
    >> enforce the spec and do not allow return statements within a finally
    >> block(thank god) AFAIK.
    >>

    >
    > Which specification prohibits return statements within a finally
    > block? Can you give a reference?



    And I'm not convinced that it is a particularly useful restriction worthy of
    any hissy fit ;) from the compiler engineers at sun. Save for a minor slap
    in the face to the structured programming zealots (which I condone anyway),
    I just don't see the problem.

    --
    Forgetthesong,I'dratherhavethefrontallobotomy...
    Thomas G. Marshall, Aug 6, 2005
    #12
  13. Patricia Shanahan coughed up:
    > wrote:
    >> My finally clauses are pretty simplistic. They look like this:
    >>
    >> finally {
    >> return(vRet);
    >> }
    >>
    >> where vRet is declared as follows.
    >>
    >> Vector vRet = new Vector();
    >>
    >>
    >> Thanks.
    >>
    >>
    >> Dennis
    >>

    >
    > Here's the issue. Without seeing the rest of your code, I don't know
    > whether you have already taking this into account and coped with it.
    >
    > When a finally clause completes abruptly, completes by throwing
    > something or returning, the whole try-catch-finally completes abruptly
    > for the same reason, losing the original completion condition.
    >
    > Suppose something went really, really bad during the try clause, and
    > an Error was thrown. Unless you are catching and logging that Error,
    > it will be completely lost when the finally returns.


    Hmmmm.... That's a fairly clear point.

    However, it still seems to me as a very small problem. Worrying about
    whether or not the catch code is /itself/ protected seems maybe a little too
    protective. I'll think on this some more.



    --
    Forgetthesong,I'dratherhavethefrontallobotomy...
    Thomas G. Marshall, Aug 6, 2005
    #13
  14. Harry Bosch Guest

    Wow, I was wrong. I swore it was in the specification. I just read
    over it and it's not there. I guess I just remembered wrong. But, I
    believe I was using a compiler that enforced this.

    But, I still say that it should not be done.
    Harry Bosch, Aug 9, 2005
    #14
  15. Dale King Guest

    Thomas G. Marshall wrote:
    > Patricia Shanahan coughed up:
    >
    > And I'm not convinced that it is a particularly useful restriction worthy of
    > any hissy fit ;) from the compiler engineers at sun. Save for a minor slap
    > in the face to the structured programming zealots (which I condone anyway),
    > I just don't see the problem.


    Then I don't think you are looking hard enough.

    Take this method:

    public int foo() throws Exception
    {
    try
    {
    bar();
    return 1;
    }
    catch( IOException e )
    {
    return 2;
    }
    finally
    {
    return 3;
    }
    }

    Quick, without thinking too hard about it, what happens in these cases:

    - bar completes normally
    - bar throws an IOException
    - bar throws an exception other IOException

    While you a seasoned veteran probably can figure out the answers don't
    you think the fact that it returns 3 in all cases might be confusing to
    a newbie?

    If there were a valid use case for having a return statement in a
    finally block then there might be a reason to not have the warning.

    Since there isn't a good use case for it and the behavior will be
    confusing to newbies and possibly cause undesirable behavior then it is
    a good idea to warn people.

    --
    Dale King
    Dale King, Aug 17, 2005
    #15
  16. Dale King coughed up:
    > Thomas G. Marshall wrote:
    >> Patricia Shanahan coughed up:
    >>
    >> And I'm not convinced that it is a particularly useful restriction
    >> worthy of any hissy fit ;) from the compiler engineers at sun. Save
    >> for a minor slap in the face to the structured programming zealots
    >> (which I condone anyway), I just don't see the problem.

    >
    > Then I don't think you are looking hard enough.


    You might not be looking hard enough at the dates of the replies. Above
    you'll see that patricia set me rethinking this already over a week ago.

    ....[rip]...


    --
    "His name was Robert Paulson. His name was Robert Paulson. His name was
    Robert Paulson..."
    Thomas G. Marshall, Aug 17, 2005
    #16
  17. Dale King Guest

    Thomas G. Marshall wrote:
    > Dale King coughed up:
    >
    >>Thomas G. Marshall wrote:
    >>
    >>>Patricia Shanahan coughed up:
    >>>
    >>>And I'm not convinced that it is a particularly useful restriction
    >>>worthy of any hissy fit ;) from the compiler engineers at sun. Save
    >>>for a minor slap in the face to the structured programming zealots
    >>>(which I condone anyway), I just don't see the problem.

    >>
    >>Then I don't think you are looking hard enough.

    >
    >
    > You might not be looking hard enough at the dates of the replies. Above
    > you'll see that patricia set me rethinking this already over a week ago.


    Unfortunately, the order they were in the thread was not the same as
    they were chronologically due to multiple thread forks. It looked to me
    like you were rethinking it then you concluded that it was not still a
    problem.

    I think the example however explained the issue concisely.

    --
    Dale King
    Dale King, Aug 26, 2005
    #17
    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. sravan reddy

    warning when using design compiler

    sravan reddy, Aug 14, 2005, in forum: VHDL
    Replies:
    0
    Views:
    481
    sravan reddy
    Aug 14, 2005
  2. Pete Becker
    Replies:
    0
    Views:
    1,368
    Pete Becker
    Feb 10, 2005
  3. B. Williams

    warning C4267 and warning C4996

    B. Williams, Oct 26, 2006, in forum: C++
    Replies:
    17
    Views:
    2,615
  4. WARNING! Prosoftstore.com is a SCAM! WARNING!

    , Jul 8, 2007, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    306
  5. Julian Mehnle
    Replies:
    17
    Views:
    853
    Julian Mehnle
    May 18, 2006
Loading...

Share This Page