C#

string abc = @"<Broker Code=""" + strbrokercode + """ IsAllowEstimate=""" + IsAllowEstimate + """ ReviseDate=""" + ReviseDate + """ BrokerEarnings=""" + BrokerEarnings + """ BrokerName="""+ BrokerName + """></Broker>";

string abc = new System.Xml.Linq.XElement("Broker",
    new System.Xml.Linq.XAttribute("Code", strbrokercode),
    new System.Xml.Linq.XAttribute("IsAllowEstimate", IsAllowEstimate),
    new System.Xml.Linq.XAttribute("ReviseDate", ReviseDate),
    new System.Xml.Linq.XAttribute("BrokerEarnings", BrokerEarnings),
    new System.Xml.Linq.XAttribute("BrokerName", BrokerName)
).ToString();

Mou_kol wrote:

i am seeing many extra back slash has been added to string variable

string strbrokercode="ML";
            string IsAllowEstimate="true";
            string ReviseDate="true";
            string BrokerEarnings="true";
            string BrokerName="true";

            StringBuilder sb = new StringBuilder();

            string abc = "<Broker Code=" + '"' + strbrokercode + '"' + " IsAllowEstimate=" + '"' + IsAllowEstimate + '"' + " ReviseDate=" + '"' + ReviseDate + '"' + " BrokerEarnings=" + '"' + BrokerEarnings + '"' + " BrokerName=" + '"' + BrokerName + '"' + "></Broker>";
            sb.Append(abc);

"<Broker Code=\"ML\" IsAllowEstimate=\"true\" ReviseDate=\"true\" BrokerEarnings=\"true\" BrokerName=\"true\"></Broker>"

using (SqlConnection connection = new SqlConnection("..."))
using (SqlCommand command = new SqlCommand("...", connection))
{
    ...
    using (SqlDataReader reader = command.ExecuteReader())
    {
        ...
    }
}

{
    SqlConnection connection = new SqlConnection("...");
    try
    {
        {
            SqlCommand command = new SqlCommand("...", connection);
            try
            {
                ...
                {
                    SqlDataReader reader = command.ExecuteReader();
                    try
                    {
                        ...
                    }
                    finally
                    {
                        if (reader != null)
                            ((IDisposable)reader).Dispose();
                    }
                }
            }
            finally
            {
                if (command != null)
                    ((IDisposable)command).Dispose();
            }
        }
    }
    finally
    {
        if (connection != null)
            ((IDisposable)connection).Dispose();
    }
}

MSBassSinger wrote:

1 - Capture of runtime data for troubleshooting.

MSBassSinger wrote:

3 - You have full control over the order and operations of releasing resources.

MSBassSinger wrote:

the hope that under the covers, MS got the "using" statement right.

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.

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.

MSBassSinger wrote:

No need for the nested try-finally blocks.

SqlConnection connection = new SqlConnection("...");
SqlCommand command = new SqlCommand("...", connection);
try
{
   ...
}
finally
{
    if (command != null) ((IDisposable)command).Dispose();
    if (connection != null) ((IDisposable)connection).Dispose();
}

SqlConnection connection = null;
SqlCommand command = null;
try
{
    connection = new SqlConnection("...");
    command = new SqlCommand("...", connection);
    ...
}
finally
{
    if (command != null) ((IDisposable)command).Dispose();
    if (connection != null) ((IDisposable)connection).Dispose();
}

Quote:

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

Quote:

A using block should be used where appropriate

Quote:

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

SqlCommand cmd = new SqlCommand(sql, con);
try
   {
   ...
   }
finally
   {
   if (cmd != null) cmd.Dispose();
   }
cmd.ExecuteNonQuery();  // Perfectly valid, cmd is in scope.

using (SqlCommand cmd = new SqlCommand(sql, con))
   {
   ...
   }
cmd.ExecuteNonQuery();  // Compiler error, cmd is not in scope.

Quote:

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

SqlCommand cmd = null;

Quote:

using is cleaner, clearer, and easier to use.

Quote:

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

Quote:

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

MSBassSinger wrote:

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.