try using blocks

[ghost]

We have to use try catch with using like this:

using(SqlConnection conn = new SqlConnection(connString))
{
    try
    {
        conn.Open();
    }
    catch(SqlException sqlEx)
    {
       MessageBox.Show(sqlEx.Message);
    }
}

or like this:

try
{
    using(SqlConnection conn = new SqlConnection(connString))
    {
        conn.Open();
    }
}
catch(SqlException sqlEx)
{
    MessageBox.Show(sqlEx.Message);
}

I suggest to shorten this to:

try using(SqlConnection conn = new SqlConnection(connString))
{
    conn.Open();
}
catch(SqlException sqlEx) 
{
   MessageBox.Show(sqlEx.Message);
}

And I suggest to use expression bodied try catch blocks if they contain only one statement to make them shorter like this:

try using(var conn = new SqlConnection(connString))
   => conn.Open();
catch(SqlException sqlEx) 
   => MessageBox.Show(sqlEx.Message);

[CyrusNajmabadi]

And I suggest to use expression bodied

Expression-bodied statements are very ambiguous as to their intent. Do they mean "return this value"? do they mean "just execute this"? Either are possible interpretations. With expression-bodied members, it is clear what has to happen as it's the only body statement for the member. With statements, it is entirely unclear.

[ghost]

@CyrusNajmabadi
try catch must have a {} pair, so it they are not found and there is =>, this means this is a one statement block.
Anyway, this is not the main suggestion. lets focus on try using:

try using(SqlConnection conn = new SqlConnection(connString))
{
    conn.Open();
    // any other code
}
catch(SqlException sqlEx) 
{
   MessageBox.Show(sqlEx.Message);
}

What do you say about that?

[lazyloader]

@MohammadHamdyGhanem Using => doesn't solve the problem that the braces solve which is the ambiguity problem. It has to do with not knowing which catch catches which try. For example:

try (...)
{
try (...) { }
catch (...) { }    // Clearly catches the second try
}

try (...)
{
try (...) { }
}
catch (...) { }    // Clearly catches the first try

try (...)
try (...) ... 
catch (...) ...    // Um...

try (...) => ...
try (...) => ...
catch (...) => ...   // Hm...?

No indenting to show the ambiguity the compiler faces, as C# indentation is ignored. You may intend for it to be:

try (...)
    try (...) => ...
    catch (...) => ...   // Catches second try, not first

or maybe:

try (...)
    try (...) => ...
catch (...) => ...   // Catches first try, not second

But that would involve the compiler assuming that and could cause bugs and crashes and errors not being crashed when you thought they would be.

[franchyd]

I'm not sure the few characters plus level of indentation saved is worth much. The number of times I have personally seen a situation where I have immediately nested try's and using's has been few if any.

Additionally its a bit unclear about the whether the using code setup and Dispose are in or out of the Try-catch scope. Would exceptions in CreateDisposable() or Dispose() be caught or no? Furthermore when does a finally occur relative to the using's Dispose(), before or after.

[ghost]

@lazyloader
This is not a new thing for C#. You can just replace nested try.. catch with nested if.. else and you will have your answer.
So, C# already knows how to deal with this.

@DanFTRX
We can set some roles to make try using work properly. One of them is that the conn var domain should be the entire try using.. catch.. finally block. You can suggest other rules.

[james-uffindell-birt]

using is already a try block under the hood, so combining it with a try keyword like that causes me to do a bit of a double-take.

As a language comparison, in Java the equivalent of the using statement just reuses the try keyword, and you can attach your own catch and finally blocks to it:

try (InputStream is = getStream()) {
    // code
} catch (Exception e) {
    // handle exception
} finally {
    // other cleanup
}

is effectively translated to

try {
    InputStream is = null;
    try {
        is = getInputStream();
        // code
    } finally {
        if (is != null) is.close();
    }
} catch (Exception e) {
    // handle exception
} finally {
    // extra cleanup
}

(although it has some extra magic in it so that if the innermost block threw an exception, but then is.close() also throws an exception, the whole block ends up rethrowing the original exception but with the exception from close() attached to it as a suppressed exception, whereas in C# I think last exception wins and the other is forgotten?)

I've sometimes wanted to attach my own catch blocks to using statements, the way I can in Java, and I would have thought a natural way to do it would just be to extend using to also allow catch and finally blocks:

using (var f = new FileStream())
{
    // code
}
catch (Exception e)
{
    // handle exception
}

(I think this would only make sense for using statements that are followed by a brace-delimited block, since otherwise you run into the same which-block-does-the-catch-statement-go-with problem as for nested try blocks.)

However, I think the 'bang-for-buck' for this feature is pretty small: it would have been nice if the using statement had allowed this all along, but I'm not sure it's worth the effort to add it now, especially given that wrapping the using in a try isn't that onerous.

[ghost]

@juffindell
I thougth of using.. catch at first but afraid it becomes confusing or break some existing code where using is nested inside try..catch, so I suggested try using instead to avoid any side effects. It doesn't acually differ from your syntax, except it is less confusing.

[franchyd]

@MohammadHamdyGhanem Try using doesn't really expand well into multi using blocks, if anything the try would need to be locked at the end.

using (var disposable1)
using (var disposable2)
try
{

}

At which point @juffindell 's syntax becomes the more ideal.

[ghost]

@DanFTRX
What about:

try using (var disposable1, var disposable2)
{

}
catch
{

}

[CyrusNajmabadi]

You can already write this:

using(SqlConnection conn = new SqlConnection(connString))
try
{
    conn.Open();
}
catch(SqlException sqlEx)
{
    MessageBox.Show(sqlEx.Message);
}

You could even write:

using(SqlConnection conn = new SqlConnection(connString)) try
{
    conn.Open();
}
catch(SqlException sqlEx)
{
    MessageBox.Show(sqlEx.Message);
}

if you really wanted to...

Now... whether or not you should do that is up to you and your team's coding preferences.

I would not personally permit that in any of my codebases. But there's nothing stopping you from using those forms today.

[DavidArno]

@CyrusNajmabadi,

Looking at your code examples, I wonder whether another solution might be possible. using gets converted to a try … finally, so why not allow catch blocks after the using:

using(SqlConnection conn = new SqlConnection(connString))
{
    conn.Open();
}
catch(SqlException sqlEx)
{
    MessageBox.Show(sqlEx.Message);
}

[ghost]

@DavidArno
On second thought, I find it nice, and can't break any thing becuase nedted using in exisiting code will be inside the {} of the try block, so old catch blocks still belong to their try blocks.

[HaloFour]

@DavidArno

I can't imagine that this comes up so frequently that three additional characters would be considered so onerous:

using(SqlConnection conn = new SqlConnection(connString)) try
{
    conn.Open();
}
catch(SqlException sqlEx)
{
    MessageBox.Show(sqlEx.Message);
}

[DavidArno]

@HaloFour,

Maybe. I've no idea how often folk nest try inside using and vice-versa in order to add catch's to their using statements.

I agree that that try isn't onerous. It was more a question of elegance and really I'm just chucking spaghetti at walls here. Also, if implicitly scoped using statements are coming to v8, I wonder how relevant this topic will then be (though they may be unrelated).

[Thaina]

@HaloFour

using(SqlConnection conn = new SqlConnection(connString))
{
    conn.Open();
}
catch(SqlException sqlEx)
{
    MessageBox.Show(sqlEx.Message);
}

should be

try
{
    using(SqlConnection conn = new SqlConnection(connString))
    {
        conn.Open();
    }
}
catch(SqlException sqlEx)
{
    MessageBox.Show(sqlEx.Message);
}

not

using(SqlConnection conn = new SqlConnection(connString))
{
    try
    {
        conn.Open();
    }
    catch(SqlException sqlEx)
    {
        MessageBox.Show(sqlEx.Message);
    }
}

And I really interest in this syntax because it shorten the try block indent

[HaloFour]

@Thaina

The net effect is the same.

C# 8.0 is already (likely) getting the following, which takes care of the indentation concern:

try {
    using var conn = new SqlConnection(connString);
    conn.Open();
}
catch (SqlException sqlEx) {
    MessageBox.Show(sqlEx.Message);
}

[Thaina]

@HaloFour It a little bit difference that if the new SqlConnection(connString); itself throw the exception, it will catch there or throw out to parent before try

And if we allow using/catch we could write it like this

using(var conn = new SqlConnection(connString))
{
    conn.Open();
}
catch (SqlException sqlEx)
{
    MessageBox.Show(sqlEx.Message);
}

Which is shorter. The point difference is, would it allow access to var conn in catch and let it be a default value (null) if it thrown from constructor?