WHy jump in this code ?

[Erik]

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;
}
}
}

 

[Andreas Leitgeb]

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

 

[Erik]

thnx

 

[Andreas Leitgeb]

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?

 

[Daniel Pitts]

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]

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.

 

[Roedy Green]

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.

 

[Driss]

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

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