0

Why do we dispose objects when we exit an application? In theory, wouldn't it be disposed of anyway when we close the program?

If not, how much could it impact the performance, that is, the amount of RAM it uses when running, if not disposed of?

Hadi
  • 36,233
  • 13
  • 65
  • 124
Ally
  • 467
  • 5
  • 24
  • https://www.mindstick.com/blog/196/application-exit-this-close-and-this-dispose: refer this page for your help. IF u dont dispose each time the memory will allocate new new objects and make the memory full. – Thomas Feb 18 '17 at 10:56
  • @JojiThomasEapen : That doesn't really answer if he needs to dispose when the application is closing. – Visual Vincent Feb 18 '17 at 11:04
  • Usually when the application exits, the Garbage Collector will collect all managed objects in the application's memory. If an object implements `IDisposable` then the GC will _usually_ call its `Dispose()` method. However this doesn't change the fact that there still could be [unmanaged] resources that the GC nor the OS knows about. -- In short, you _**usually**_ don't need to call `Dispose()` yourself as the GC would do that for you. However it isn't bad practice. – Visual Vincent Feb 18 '17 at 11:11
  • @Hadi, no, this is just in general, not necessarily in Main(). – Ally Feb 18 '17 at 11:14
  • Also keep in mind that a badly implemented `Dispose()` method could miss releasing unmanaged resources, in which case calling `Dispose()` or not doesn't matter. If that's the case then there might not be much you can do unless you have access to that object's source code. For the native .NET Framework objects this shouldn't be a problem though. I'm sure Microsoft know what they're doing. ;) – Visual Vincent Feb 18 '17 at 11:17
  • `this is just in general, not necessarily in Main().` - Doesn't matter if it's in `Main()` or not, the application still exits the same way. There is always a defined entry point, whether it's called `Main` or anything else. In VB.NET you usually don't edit this entry point like you do in C#'s `Program.cs` file's `Main` method. – Visual Vincent Feb 18 '17 at 11:19
  • @VisualVincent may I ask, I've seen the entry point for C# which is very much visible, so what would the entry point for VB.NET be if I can't see it? – Ally Feb 18 '17 at 11:21
  • It's a bit uncertain what exactly is VB.NET's entry point. When using WinForms it seems to be built into the framework. There isn't any code file that acts as a specific entry point. The closest you can come is the `\My Project\Application.Designer.vb` file, which includes code for when the `My.Application` class is initialized and when the main form is created. – Visual Vincent Feb 18 '17 at 11:31
  • If you uncheck the `Enable application framework` box in the application settings that allows you to define your own entry point (just like C#'s `Main()`). However then some other things like disabling compatible text rendering and enabling visual styles would have to be done by you as it is no longer done automatically. – Visual Vincent Feb 18 '17 at 11:35
  • Therefore it could be considered that this question is in fact **not** a duplicate? Although I didn't clarify the context in the question. – Ally Feb 18 '17 at 11:36
  • 1
    No, it's still a duplicate because every application exits the same way: by returning from the main entry point, however defined. The Garbage Collector then runs after that. And if the GC doesn't collect it, the OS does if it's aware of the resource. – Visual Vincent Feb 18 '17 at 11:38
  • Can I just ask why the further downvote on the question? I get it's a duplicate, but I'd just like to know. Oh, and thanks @VisualVincent, quite insightful. – Ally Feb 18 '17 at 14:27
  • I didn't downvote you, however someone upvoted you as well so you've at least gained 3 rep. :) – Visual Vincent Feb 18 '17 at 14:33
  • This sort of question has lingered around for years and sometime here on SO, it's always being brought up in some fasion or another. Also at the same time it's off topic here, I don't see any code in your question you need help with, you are ***asking for opinions*** and it's also a broad question. This put into Google yields thousands of results, why add another? It's sad to say as well, ***some*** ignore the fact we are trying to keep SO relevant and not just another dictionary to maintain... – Trevor Feb 18 '17 at 14:42
  • From the original question, I'm not asking for opinions at all @Zaggler. Additionally, it's not very broad - and if it is so, in what way? Everyone here, bar myself, have been able to accurately answer this, thus far. – Ally Feb 18 '17 at 14:45
  • Of course you will get an answer, what do you think when asking a question, you will get opinions... It is broad as well, implementation etc... – Trevor Feb 18 '17 at 14:47
  • Sorry, didn't mean to imply you downvoted @VisualVincent, just in general is all. – Ally Feb 18 '17 at 14:47
  • @Zaggler while I might get opinions as a result of a question, that'll generally apply to **any questions asked**. So why would this specifically be opinionated? – Ally Feb 18 '17 at 14:49
  • Because you don't have any code in question, therefore according to SO it's off topic. We help with code related questions, not do research... If you had a ***specific issue*** then that's entirely different. Hence why your question was closed yesterday... – Trevor Feb 18 '17 at 14:51

2 Answers2

3

If you take the IDisposable contract seriously then, no, disposing anything just before the program terminates makes no sense. As part of the shutdown procedure, the CLR runs the finalizers of any remaining objects. So the cleanup happens anyway, calling Dispose() does not make it any quicker and has no effect at all on resource usage.

A word of caution is appropriate however. The contract does not always get used the way it was intended. It is very common to have to do some cleanup after using an object and very easy to forget to do so. The Using statement in particular is very attractive to make that semi-automatic. You can see me abuse the heck out of it in this answer. I went for it because it was convenient and impossible to not notice that you forgot to dispose. A pretty innocent fib. But it is not always that innocent. Something like using Dispose() to unsubscribe events is a pretty common crime for example. Not innocent, that's a leak when the client programmer doesn't dispose. Albeit that it still isn't a bug when it is skipped at program shutdown. But it could well be worse, like deleting a file or sending a "goodbye" message to another machine.

So the rough guidance is that you'll never have to be sorry for disposing anyway and it is a good habit to get into. Particularly so if it is somebody else's code. But much less so if it is .NET Framework class, I can't think of a concrete case right now where it abuses the contract.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
2

Although, under normal circumstances, allowing the system to properly fold up the application and release resources and file locks etc. is normally sufficient, there are other reasons why you might want to run a dispose on termination of an application.

For example, if you are connecting to a remote location or a database and have checked out a key of some sort, proper termination should involve returning that key and properly closing the connection at the other end.

Further, you may be using temporary files for logging or other purposes. It is good programming manners to also clean those up when your application exits.

Trevor_G
  • 1,331
  • 1
  • 8
  • 17