Z
Zytan
I know that WebRequest.GetResponse can throw WebException from
internet tutorials. However in the MSDN docs:
http://msdn2.microsoft.com/en-us/library/system.net.webrequest.getresponse.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/library/system.net.webrequest.getrequeststream.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
internet tutorials. However in the MSDN docs:
http://msdn2.microsoft.com/en-us/library/system.net.webrequest.getresponse.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/library/system.net.webrequest.getrequeststream.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