C#

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:

Thank you for all your help - you really inspired me.
It was a very very old problem and now you 'confirmed' it to me. Thats why im so thankful. And pointing that was more a design issue and not a compile issue, cemented it for me.

Are you sure the root is correct?
What i did: I created a new alb.jpg file into (your specified folder root):
"c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
and the code now checks if in 'DesignMode', then load the default alb.jpg image.
Else, is runtime and load the normal image.
here is my code:

On top of what Richard said, for custom controls where you have images that don't change and are a mandatory part of your control, you should probably move the images to Resources instead of leaving them in files. You can then load the image from your controls Resource and you won't have any problems with managing files on the drive.