Timeline for How assertive should I be in handling exceptions in objects?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 29, 2022 at 8:31 | comment | added | JonasH | I would note that it is not that uncommon with memory "leaks" in .net, by not removing references to objects that are no longer used. Even if this would not be considered a "leak" in the c/c++ sense. A Typical case would be periodically adding event handlers to a long lived UI object. | |
| Dec 13, 2011 at 20:14 | comment | added | one.beat.consumer | +1 Thanks for clarifying. If you edit your answer to address the exception handling concern about minimizing bloat from excessive catch blocks, I'll mark yours as the answer. @Kor got part of it, but he's not on Programmers exchange either it seems. | |
| Dec 13, 2011 at 19:57 | comment | added | mqp |
No. The garbage collector works exactly the same way with a SqlConnection as it does with any other heap-allocated object. It will remove it from memory whether or not you call Dispose. Calling Dispose has absolutely zero effect on whether or not the garbage collector will remove your object from memory or when. The only difference is that if you call Dispose early, the other important non-memory resources will be cleaned up early.
|
|
| Dec 13, 2011 at 19:53 | comment | added | one.beat.consumer | Thanks Kor for clarifying a bit... its the 5% I'm getting at... and items the garbage collection cannot automatically dispose (SqlConnection, etc.). Those are still items in memory, no? As well as locked in resources. | |
| Dec 13, 2011 at 19:34 | history | migrated | from stackoverflow.com (revisions) | ||
| Dec 13, 2011 at 19:32 | comment | added | mquander |
* (Note: This is 95% of the truth. The other 5% is that when the garbage collector actually collects the object, the finalizer will run, and when the finalizer runs, it will call Dispose if you didn't already call Dispose yourself. However, since file handles and other similar things are important resources, it's bad to just wait and hope that the garbage collector will get around to it, so you should call Dispose yourself.)
|
|
| Dec 13, 2011 at 19:30 | comment | added | mquander |
No, definitely not! The problem is not that the StreamWriter is lingering in memory. The problem is (e.g. if you're writing to a file) that the StreamWriter, when opened, told Windows that it was taking control of a file, and never relinquished it when it was done, which means that other processes are probably locked out of writing to the same file. Calling Dispose in this case releases the file handle. Whether or not the StreamWriter is in memory hardly matters.*
|
|
| Dec 13, 2011 at 19:28 | comment | added | one.beat.consumer |
Thanks for the reply. I guess not "leaks" per se, but objects no longer needed lingering in memory? Isn't the StreamWriter scenario a common one where without a using statement it could potentially linger around in memory until the garbage collector decides its ready for the trash can? Perhaps I need to relearn what I thought I knew. :(
|
|
| Dec 13, 2011 at 19:18 | history | answered | mqp | CC BY-SA 3.0 |