In general, catching a thrown exception versus checking a status code (or
a null check, or whatever) is a style issue. Throwing exceptions for 4XX
and 5XX http responses is perfectly reasonable; they're error
conditions. However, were the argument that httpclient should be
lightweight and not use exception propagation (which is object creation,
some might argue, that is gratuitous) for performance reasons, IMO _that_
is the issue that API designers better agree on (a vote being, "do we
want a more OO error handling mechanism or a better performing one?").
On Mon, 27 Aug 2001, Sale, Doug wrote:
> morgan:
> > Aren't the headers available in the method ? If not, we should change
> that.
> > Returning an error code or throwing an exception, it's just a matter of
> taste,
> > you always have to do a test and with exceptions the compiler reminds you.
>
> returning an error code? it's an HTTP *status* code. it doesn't indicate
> an excpetion condition in the httpclient. if an application that uses
> httpclient wants to throw an exception when receiving an unfavorable HTTP
> *status* code, that is it's choice.
cheers,
-Ian
--
Ian Kallen <[EMAIL PROTECTED]> | AIM: iankallen
