The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Dear all,I had written a webserver use HttpListener, when i respon data to client, some time it show error: System.Net.HttpListenerException (0x80004005): The specified network name is no longer available
at System.Net.HttpResponseStream.Write(Byte buffer, Int32 offset, Int32 size)
Can anyone give me a help or suggestion?
Thanks very much.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
I read the article from the Insider[^] about properties and methods and the author states
Properties should be stable: that is, the value of a property shouldn't change “on its own". Rather, changes in properties are the results of calling property setters, or some other action changing the state of the object
So the mass of a car can be a property since it doesn't change, but the total mass, including fuel, can't be since fuel is burned and so changes.
A specific example is DateIime.Now which should not be a property because it changes and really ought to have been a method GetCurrentDateIime.
I'm assuming the author means we should have a IimeZone object with a Now property, with Now being updated explicitly through some process such as TimeZone.Now = DateTime.GetCurrentDateIime(). Which seems a great way to spend your spare CPU cycles.
Can someone smarter than me please explain why properties should only be things that can't change? To stretch the car analogy if you have an Engine and Radiator object with the Radiator having a property Temperature then I can accept the argument that the water doesn't get hotter on its own. You'd have something like
But what of the Car object that aggregates an Engine and a Radiator object? The car's EngineIemperature property (which is a façade for the Engine.Temperature property) is going to change "on its own" sorta kinda. It'll change due to changes passed on by internal objects.
The author states
Property getters should always succeed: they should never throw an exception. Return some reasonable default value if the property cannot be logically computed right now because the object is in a bad state.
Doesn't this fly in the face of the "use exceptions not error codes" argument. I understand we're not talking about returning an error code - we're talking about completely hiding the fact that there was an error and simply returning a value that is "reasonable". In fact aren't we simply bypassing the entire exception-vs-errorcode debate and simply ignore it?
Sure - you can return null values for properties that don't currently exist on an object, but what if a property is expansive to retrieve and a timeout / resource error / whatever happens while querying the property. Surely something should be mentioned to the caller that may the value they have is a little dodgy and maybe they should try again later?
All in all this seems like a discussion on theoretical guidelines that ignore important realities.
What are your thoughts? Where am I going wrong in my thinking here?