So, I want to call WebResponse.GetResponseStream, and how am I
supposed to know what exceptions it may throw?
The documentation for the derived class that implements the
functionality of GetResponseStream should indicate this. I would say that
if there are known specific exceptions that can be thrown in situations, it
should be documented.
Yes, I predicted that the derived classes would show this information,
and they do. So, the problem is: If I must use the base abstract
class, how am I to know which of the derived classes will be invoked?
In the case of WebResponse, it could be HttpWebResponse or
FileWebResponse. So, I basically have to look at all of them to know
which exceptions each of them may throw.
http://msdn2.microsoft.com/en-us/lib...request.getreq...
I'm betting it throws WebException, but no where is it mentioned that
it does.
Nor should it. You are looking at the documentation for the base class.
Trying to list out all the exceptions that a method can throw becomes an
exercise in futility due to the large number of exceptions that can be
thrown anywhere due to factors outside of the programmers control (out of
memory exceptions, thread abort exceptions, and THEN you have any exceptions
that a derived class can throw, which is up to the person implementing the
derived class).
Right. But consider that these aren't classes I programmed. And
HttpWebRequest even recommends to use the base abstract class for
construction. And the derived classes appear to throw exceptions that
'look' like the base abstract class - WebException (not
HttpWebException or FileWebException), so it the class was designed
such that it 'appears' you are using a 'normal' class, not an abstract
class. So, why can't it tell me information about the derived
classes?
But, I guess you're right in that the format of MSDN shows only
exceptions that the class you are looking at throws, which makes
sense, since otherwise, there's dependencies. So, it shouldn't be
mentioned under the Exceptions section, I agree.
But, it still seems it really should in the Remarks section. I just
fail to see how anyone is supposed to know about all these possible
exceptions without looking into every derived class. I guess that's
the only solution, though.
Oh wait! For WebRequest.GetRequestStream it does! :) So, someone
agrees with me.
http://msdn2.microsoft.com/en-us/lib...eststream.aspx
"The WebRequest class is an abstract class. The actual behavior of
WebRequest instances at run time is determined by the descendant class
returned by the System.Net.WebRequest.Create method. For more
information about default values and exceptions, see the documentation
for the descendant classes, such as HttpWebRequest and
FileWebRequest."
The docs for WebResponse.GetResponseStream just aren't so nice.
If you know that you are going to be working with a specific protocol,
then by all means, use that specific class. However, if you are going to
use generic functionality that is applicable to many implementations of the
base class, and protocol is not an issue, use a variable of the type of the
base class.
Right, and I agree. Except that HttpWebRequest exclaims that I MUST
use the base abstract class! This means that I could get any of the
derived classes as a result. Life would be easier if I could just say
I wanted to use HTTP only.
Interesting, when I look at the documentation for the GetRequestStream
and GetResponse methods, there is a nice list of specific exceptions that
can be thrown and the situations that they will be thrown in.
Yes, for the derived classes, I know, and I expected that. That
wasn't the issue. My issue was when I am using the abstract class,
how can I know which exceptions may appear? I had no idea even what
classes were derived from it. Some of the abstract methods do mention
their derivatives, though, which is nice. I wish they all did.
The quote you have has nothing to do with exceptions, but rather, how
you should create the specific implementation of the HttpWebRequest. Yes,
you should use the static create method to initialize new HttpWebRequest
objects, as the constructor does not do the specific work, and the model for
creating WebRequest-derived classes is a factory model. If you need to work
with the specific type, then cast to the specific type.
Yes, but using the base constructor means I could end up with any of
the derived classes, so I must be prepared for all of them. I would
rather just use the derived class that I need.
Hope this helps.
Yes, it does, thanks for your time, Nicholas.
Zytan