By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,152 Members | 2,039 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,152 IT Pros & Developers. It's quick & easy.

what exceptions do abstract classes (WebRequest) throw?

P: n/a
I know that WebRequest.GetResponse can throw WebException from
internet tutorials. However in the MSDN docs:
http://msdn2.microsoft.com/en-us/lib...tresponse.aspx
It only lists NotImplementedException in the Exceptions section.
(Note that it does mention WebException in the Remarks section, but
who knows if this is always the case for such classes, and thus
perhaps they can't be trusted to always list these, and even if it is
trustworthy, why isn't in mentioned in the Exceptions section? It IS
an exception, after all.)

So, I want to call WebResponse.GetResponseStream, and how am I
supposed to know what exceptions it may throw?
http://msdn2.microsoft.com/en-us/lib...eststream.aspx
I'm betting it throws WebException, but no where is it mentioned that
it does.

Examples on the internet use the WebRequest class directly. But,
should I (and they) be using one of the derived classes directly? And
thus, I assume, those classes' MSDN docs would list what exceptions
they throw? How can anyone use an abstract class without knowing
about what exceptions are possibly thrown? That sounds like a
horrible programming practice to me.

If I know I will be always using HTTP, then there's no reason to not
exclusively use HttpWebRequest, instead of the abstract WebRequest,
and I bet its docs show what exceptions it may throw. Hm, no, wait,
it says: "Do not use the HttpWebRequest constructor. Use the
System.Net.WebRequest.Create method to initialize new HttpWebRequest
objects." so you really should use WebRequest unless there's a reason
not to.

This is just confusing... do people just not care that things can
throw exceptions? We're talking about internet connections which are
not exaclty infallible. We should handle the exceptions that are
likely to happen.

Zytan

Mar 21 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Zytan,

See inline:
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.
http://msdn2.microsoft.com/en-us/lib...eststream.aspx
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).
Examples on the internet use the WebRequest class directly. But,
should I (and they) be using one of the derived classes directly? And
thus, I assume, those classes' MSDN docs would list what exceptions
they throw? How can anyone use an abstract class without knowing
about what exceptions are possibly thrown? That sounds like a
horrible programming practice to me.
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.
If I know I will be always using HTTP, then there's no reason to not
exclusively use HttpWebRequest, instead of the abstract WebRequest,
and I bet its docs show what exceptions it may throw. Hm, no, wait,
it says: "Do not use the HttpWebRequest constructor. Use the
System.Net.WebRequest.Create method to initialize new HttpWebRequest
objects." so you really should use WebRequest unless there's a reason
not to.
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.

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.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
Mar 21 '07 #2

P: n/a
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

Mar 21 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.