Prev: Static Class Variables and IE8 Loosely Couple Internet Explorer (LCIE)
Next: best simple Java ETL
From: Erik on 13 Jan 2010 07:43
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;
}
}
}
From: Andreas Leitgeb on 13 Jan 2010 08:07
Erik <et57(a)hotmail.com> 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).

From: Erik on 13 Jan 2010 11:11
thnx
From: Peter Duniho on 13 Jan 2010 12:45
Andreas Leitgeb wrote:
> Erik <et57(a)hotmail.com> 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).

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 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), 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 find that if most users can get by fine with the default, it's easier
to just inform them if they do manage to run out of heap, and only
provide the more detailed instructions for running the program to those
who really need it.

Pete
From: Andreas Leitgeb on 13 Jan 2010 13:07
Peter Duniho <NpOeStPeAdM(a)NnOwSlPiAnMk.com> 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?

 |  Next  |  Last
Pages: 1 2 3
Prev: Static Class Variables and IE8 Loosely Couple Internet Explorer (LCIE)
Next: best simple Java ETL