C#

Yes, even more so I would avoid the using statement. However, your alternative code is nothing like what I would write. No need for the nested try-finally blocks.

Quote:

There's nothing stopping you from putting a try..catch block either inside or outside of your using block. You can still add any extra data to the exception as required.

Then why bother with the using statements? They are redundant.

Quote:

Disposable objects should be responsible for cleaning up their own resources. It shouldn't be up to the caller to know that they need to clean up a child collection before calling Dispose.

As I said, not all objects that utilize resources inherit IDisposable. They *should*, and when they do, they *should* completely clean up their resources. By having a consistent practice of not using the using statement and coding the try-catch-finally blocks, I have better step-through debugging and better control over cleaning up my resources for when those edge case situations occur.

I am not saying it is "wrong" to use the using statement. I am merely saying why, after years of experience, I choose not to use it.

I appreciate that you responded, and it does go to the point of understanding why others do choose to use the using statement.

Without them, you can easily introduce bugs where resources don't get cleaned up.

Example #1 is something only a novice would do, and novices have manifold ways of introducing bugs. Your 2nd example is exactly what I do - no bugs introduced. And in that example, it only adds two lines of code.

So yes, I much prefer the 2nd example over the using statement(s) for the flexibility I described in the OP. And it doesn't slow me down. After all, coding is only a fraction of the time wed spend doing software development.

Again, If you don't care about your items 1, 2, and 3 for a certain block of code, then a using block is just fine.

If I build a SqlConnection and SqlCommand, do I really care about your list of items? Nope. I'm going to concerned with just two things. Any exceptions thrown by the Command and the data returned. That's scoped to the inside of the using block. The method this block is in is either going to let the exception bubble up or it's going to return data. Nothing more.

I'm going to concerned with just two things. Any exceptions thrown by the Command and the data returned.

I understand and agree with what you say. But, I look for more. When something does go wrong in production, I'd like the debug log to have captured the runtime values of what I was using in the SqlConnection and SqlCommand object. With those, I can quickly tell if there was something wrong with the values (e.g. did someone diddle with a config file that had connection info?). Or maybe some of my query parameter values were unexpected. In any case, by having captured them in a catch block, I spend 5 minutes on solving a problem, instead of an hour or more guessing at what might have caused it. I could embed a try-catch within the using statement (not sure if the instantiation portion of the using statement would get "caught" in the catch block, though), but then if I have the try-catch, why not just add finally and do away with the redundancy of the using statement?

If the values seem OK, with the try-catch-finally, I can step through all the code, which is limited with the using statement.

I understand if these things are not valuable to you. But they are to me after many years of running into the odd issues that could have been solved by a couple more lines of code. Every developer has to pick and chose what they consider valuable to them, as well as to a customer.

I have to agree with Richard - using is cleaner, clearer, and easier to use.

And ... it makes the scope of the variable very, very obvious which a try...finally block doesn't - when you use the try...finally version, the scope of the variable is the block which contains the try...finally code (or it wouldn't be available for Dispose in the finally block) so you could write code to use a variable after it's content is Disposed:

And ... it makes the scope of the variable very, very obvious which a try...finally block doesn't

Looks pretty obvious to me.

First, I would make the declaration statement as:

SqlCommand cmd = null;

since I would want the instantiation within the try block.

Your second example would be caught in the IDE, before you even tried to compile.

I agree that

Quote:

using is cleaner, clearer, and easier to use.

But easier does not always lead to better, more reliable, or less buggy. For the small amount of extra effort to use try-catch-finally, it seems to me to be worth the effort. I've run into objects created via the using statement that left me with odd behavior that could not be stepped through in a using statement. But once I did away with the using statement, and used try-catch-finally, I found the problem and corrected it within minutes. So to avoid these unnecessary, but rare issues, I don't take shortcuts like the using statement. I realize the responsibility is 100% on me to cleanup the objects I create, and I am OK with that.

you do realise that VS does a partial compilation while you type I assume

Of course. Even the VB IDE did that back in the days before .NET. I was referring to when you would compile the project, not what the IDE was doing in the background, which is why the UI can tell you there is a problem.

But easier does not always lead to better, more reliable, or less buggy. For the small amount of extra effort to use try-catch-finally, it seems to me to be worth the effort. I've run into objects created via the using statement that left me with odd behavior that could not be stepped through in a using statement. But once I did away with the using statement, and used try-catch-finally, I found the problem and corrected it within minutes. So to avoid these unnecessary, but rare issues, I don't take shortcuts like the using statement. I realize the responsibility is 100% on me to cleanup the objects I create, and I am OK with that.

Then don't use a using. It's your preference.

You seem to be looking for someone to refute your case for avoiding using. That's not going to happen.

The folks who responded so far have given some good insight as to why they use the using statement. I appreciate that they took the time to engage in a conversation about the topic. I understand those who do use it a bit better now.

I want to make it clear that although I would rarely choose to use it, that is my choice in the environments and contexts that I work in. I am in no place to judge someone else's choice, and I do not intend to imply that by this thread.

The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects

I came of think of this, I wrote an application quite a while ago that did the same thing using .NET framework, I think I used System.Drawing to capture the graphics from the screen—maybe something else, please see there.

"
the image "google.png" is in this folder:
D:\Programe\Info\Visual Studio 2010\Projects\Web\FFtabs\FFtabs\bin\Debug\
from the same folder where the executable is running!
Why is doing this? Please help me. I fight with this problem for years and I always had problems with loading images in VS.
I think is a root problem of some sort. Is there a rule that i missed it? I searched on all the internet (in time) for this problem but i never find a solution.- My solution is NOT to load any image!!, and the code is running fine again, control is adding fine to form1,etc.
Thank you.

The problem is that when the code runs in the design view, the current directory is the Visual Studio application directory, not your project's directory. The file C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\google.png doesn't exist, so the Bitmap constructor throws an exception.

You can use the DesignMode property[^] to test whether your control is in design mode. You should probably also check that the file hasn't been deleted: