WHy jump in this code ?

Discussion in 'Java' started by Erik, Jan 13, 2010.

  1. Erik

    Erik Guest

    In the following coe, at the indicated line (// <<==) , why would the
    the computer jump to "finally" and forget about the following lines ?
    Stepping through the code shows that behaviour.
    If I take out the "finally" and just "return ret;", it DOES execute
    the following lines and it does not jump to any "catch"...

    According to the javadoc, PostMethod does not throw any exceptions.
    Which sounds weird to me.



    import java.io.File;
    import java.io.IOException;

    import org.apache.commons.httpclient.*;
    import org.apache.commons.httpclient.methods.*;
    import org.apache.commons.httpclient.methods.multipart.*;


    import org.apache.commons.httpclient.params.HttpMethodParams;


    public class CSSValidator {

    public boolean validateFile( String fn ) {

    boolean ret = false;
    try {
    PostMethod method;
    HttpClient client = new HttpClient();
    method = new
    PostMethod("http://jigsaw.w3.org/css-validator/validator"); // <<==


    method.setRequestHeader("Accept","text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8");
    method.setRequestHeader("Accept-Language","en-us,en;q=0.5");
    method.setRequestHeader("Accept-Encoding","gzip,deflate");

    method.setRequestHeader("Accept-CharSet","ISO-8859-1,utf-8;q=0.7,*;q=0.7");

    method.setRequestHeader("Referer","http://jigsaw.w3.org/css-validator/");

    method.getParams().setBooleanParameter(HttpMethodParams.USE_EXPECT_CONTINUE,
    false);

    Part[] parts = {
    new FilePart("file",new File(fn)),
    new StringPart("usermedium","all"),
    new StringPart("lang","en"),
    new StringPart("profile","css21"),
    new StringPart("warning","1")
    } ;

    method.setRequestEntity(new MultipartRequestEntity(parts,
    method.getParams()) );


    client.getHttpConnectionManager().getParams().setConnectionTimeout(5000);
    int status = client.executeMethod((HttpMethod) method);


    if (status == HttpStatus.SC_OK) {
    System.out.println("OK");
    ret = true;
    } else {
    System.out.println("Not OK");
    }
    }
    catch (HttpException e) {
    System.out.println("ERROR: " + e.getClass().getName() + "
    "+ e.getMessage());
    e.printStackTrace();
    }
    catch (IOException ioe) {
    System.out.println("ERROR: " + ioe.getClass().getName() +
    " "+ ioe.getMessage());
    ioe.printStackTrace();
    }
    catch (Exception ex) {
    System.out.println("ERROR: " + ex.getClass().getName() + "
    "+ ex.getMessage());
    ex.printStackTrace();
    }
    finally {
    return ret;
    }
    }
    }
    Erik, Jan 13, 2010
    #1
    1. Advertising

  2. Erik <> wrote:
    > In the following coe, at the indicated line (// <<==) , why would the
    > the computer jump to "finally" and forget about the following lines ?


    > try {
    > [...]
    > method = new PostMethod("http://[...]/validator"); // <<==
    > [...]
    > }
    > [catches: HttpException, IOException, Exception]
    > finally { [...] }


    Have you tried adding a catch (Throwable t) just for checking?
    Exceptions are not the only thing that can be thrown...

    PS: That would be only for analyzing the problem at hand. I guess
    many here would strongly frown at a catch (Throwable t) in production
    code, and even frown at the catch(Exception e).
    Andreas Leitgeb, Jan 13, 2010
    #2
    1. Advertising

  3. Erik

    Erik Guest

    thnx
    Erik, Jan 13, 2010
    #3
  4. Peter Duniho <> wrote:
    > IMHO, Throwable can still be worth catching. In fact, just the other
    > day I wrote some code that did, to detect when an attempt to allocate an
    > array that is too large for the current heap failed.


    I might be wrong here, but wouldn't it be better to catch the OOM-Error
    explictely for these matters rather than Throwable?
    Andreas Leitgeb, Jan 13, 2010
    #4
  5. Erik

    Daniel Pitts Guest

    Peter Duniho wrote:
    > Andreas Leitgeb wrote:
    >> Peter Duniho <> wrote:
    >>> IMHO, Throwable can still be worth catching. In fact, just the other
    >>> day I wrote some code that did, to detect when an attempt to allocate
    >>> an array that is too large for the current heap failed.

    >>
    >> I might be wrong here, but wouldn't it be better to catch the
    >> OOM-Error explictely for these matters rather than Throwable?

    >
    > Right, sorry. My point is that a Throwable sub-class isn't necessarily
    > a bad thing to catch. Just because the base class isn't Exception,
    > there still may be value in catching a Throwable instance.
    >
    > Pete

    Actually, OOM exceptions aren't as useful to catch as they appear at
    first glance. You can't really tell if you went a little over the top,
    or if some other thread is hogging your memory, or if you went way over
    the available memory.

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Jan 13, 2010
    #5
  6. Erik

    Daniel Pitts Guest

    Peter Duniho wrote:
    > Daniel Pitts wrote:
    >> Actually, OOM exceptions aren't as useful to catch as they appear at
    >> first glance. You can't really tell if you went a little over the
    >> top, or if some other thread is hogging your memory, or if you went
    >> way over the available memory.

    >
    > I agree with the latter. But I don't see why that implies the former.
    >
    > A serious OOM issue will eventually take down the program, without it
    > being able to do anything about it. But a simple "this single data
    > structure is just too big to handle" error is still worth recovering
    > from, as the program remains in a perfectly usable state.

    But, what if you use the last drop of the memory, and some other thread
    allocates a small object. That *other* thread will get an OOM for no
    apparent reason, and may not be able to recover as gracefully. Catching
    OOM from a large allocation might seem useful, but you can still
    destabilize your application in unexpected ways.
    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Jan 13, 2010
    #6
  7. Erik

    Roedy Green Guest

    On Wed, 13 Jan 2010 13:43:51 +0100, Erik <> wrote,
    quoted or indirectly quoted someone who said :

    >the computer jump to "finally" a


    You can use a hammer as a can opener, but that is not its intended
    use. Similarly for finally.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one’s contributions to computer science.
    ~ Donald Ervin Knuth (born: 1938-01-10 age: 72)
    Roedy Green, Jan 14, 2010
    #7
  8. Erik

    Driss Guest

    On Jan 13, 6:45 pm, Peter Duniho <> wrote:
    > Andreas Leitgeb wrote:

    ....
    > > PS: That would be only for analyzing the problem at hand. I guess
    > >   many here would strongly frown at a catch (Throwable t) in production
    > >   code, and even frown at the catch(Exception e).

    >
    > IMHO, Throwable can still be worth catching.  In fact, just the other
    > day I wrote some code that did, to detect when an attempt to allocate an
    > array that is too large for the current heap failed.


    Definitely.

    Another very valid reason to use them is to report the problem.

    We've got a client-side application that "phones home" (the user know
    about the feature) one of our Webapp server when it catches a
    Throwable
    that shouldn't have happened): it is sending us a Base64 encoded
    Proguarded stack trace.

    Moreover there's a whole category of "self healing" cases where you
    can have a non-essential functionality of a software crashing that
    should not take down the whole program.


    > I suppose some may argue that the Java program should just always be
    > initialized with a large enough heap, but in this case a) unfortunately,
    > because of the way Java works, it is not really all that practical to
    > deliver simple Java programs to arbitrary users while ensuring the heap
    > size is set larger than the default (i.e. as far as I know, there's no
    > way to configure that setting within the .jar file itself),


    On Windows we went with a hack where a java 'stub' takes care of
    invoking the "real" jar with the correct JVM parameters (in our
    case the -Xmx parameter depends on how much memory the system has).

    On OS X we use a Bash shell script that sets the correct JVM
    parameters
    before calling the OS X Java stub (which itself calls our 'real' jar).


    > ... and b) there
    > would still always be the possibility of exceeding what's available, but
    > in a completely recoverable way, no matter what the heap size is set to.


    I 100% agree with that too :)
    Driss, Jan 17, 2010
    #8
    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. ad

    Why not jump to TimeOut.htm

    ad, Dec 22, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    386
  2. Jinming Xu

    Why cannot jump out the loop?

    Jinming Xu, Apr 30, 2004, in forum: Python
    Replies:
    1
    Views:
    316
    =?iso-8859-1?q?Beno=EEt_Dejean?=
    Apr 30, 2004
  3. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    862
    Mark Rae
    Dec 21, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,762
    Smokey Grindel
    Dec 2, 2006
  5. Eadwine Rose
    Replies:
    2
    Views:
    202
    Eadwine Rose
    Oct 15, 2006
Loading...

Share This Page