Error stop Http Listener

Quote:

---

Originally Posted by TheCPUWizard

IDisposable interface was completely available in .Net 1.1

---

Yes. I referred to .Net 1.0. As far a subtle bugs.. As I mentioned earlier, if you want to check an open connection (or IsListening) before closing it you still have that option if you think that helps you not write bugs.

Thanks Arjay,


1.

I read your points again. I think your points are, in current design of CLR, there is no need to check whether a connection is open before close a database connection, but there is need to check whether an HttpListener is listening and active before Stops it, right?

(my English understanding is not very good, please feel free to correct me if I understand your last two posts wrong).

2.

What is the underlying reason for the design? Any easy way to remember such rules? :wave: ;)

Quote:

---

Originally Posted by Arjay

Yes. I referred to .Net 1.0. As far a subtle bugs.. As I mentioned earlier, if you want to check an open connection (or IsListening) before closing it you still have that option if you think that helps you not write bugs.

---

regards,
George

Quote:

---

Originally Posted by George2

1. I read your points again. I think your points are, in current design of CLR, there is no need to check whether a connection is open before close a database connection, but there is need to check whether an HttpListener is listening and active before Stops it, right?

---

George, from now on when you start using a framework object that has a Open() and Close() method, just test it out by calling Close() without calling Open(). If it throws an error, look around for another state type of property to tell you that the object has been Opened before you close it. If you don't find one, and the object throws an error, you are going to have to track the state on your own.

Quote:

---

Originally Posted by George2

2. What is the underlying reason for the design? Any easy way to remember such rules?

---

George I don't have enough time to learn or remember trivial things like this. The interface that the object exposes is what you have to work with. It may be good, it may not be, but it is what you have. As far as an easy way to remember, just test it like I suggested in the answer to 1. That way you won't need to remember it.

I always liked the adage of "Why remember something that you can look up?"

Thanks Arjay,

Quote:

---

Originally Posted by Arjay

George I don't have enough time to learn or remember trivial things like this. The interface that the object exposes is what you have to work with. It may be good, it may not be, but it is what you have. As far as an easy way to remember, just test it like I suggested in the answer to 1. That way you won't need to remember it.

I always liked the adage of "Why remember something that you can look up?"

---

There are two design patterns, one is to let developer to check open status before call close, the other is to let developer call close without the need to check open status.

Sounds the latter one is always good since it is automatic management. But why some classes -- even if CLR classes are designed in the first pattern? Any benefits of the pattern?

(I read CPU's reply before that looks like both patterns have advantages, but actually I can not think of the 1st pattern has any advantages since it will let developer to do too many works manually, and prone to error if developer forgets to check open status before call close.)

Any comments?


regards,
George