try var

[joycestick]

I find I often have a try block with just a function call in it, the return value of which I need outside the scope of the try, e.g.

double x;
try
{
    x = GetValue();
}
catch (SomeException e)
{
    // deal with exception
}
// do something with x

The only real drawbacks of the above code are explicit type declaration (I'd rather use var) and number of lines of code, so this suggestion is only a bit of sugar, but I wondered if something like the following would be possible:

try var x = GetValue();
catch (SomeException e)
{
    // deal with exception
}
// do something with x

EDIT: It has been noted that in both cases x will be uninitialised at the point of // do something with x if GetValue() throws an exception and the catch block doesn't assign x. This suggestion does not attempt to address that issue.

I've had a good look for this suggestion as already existing and can't find anything, but apologies if it's a duplicate.

Also, any suggestion around try-catch seems to be pretty contentious, but I'm hoping this one isn't as offensive as asking for an On Error Resume Next equivalent.

[canton7]

I think expression statements might cover this case: it's mentioned as a case here.

If I'm reading it right, something like:

double x = {
    try
    {
        break GetValue();
    }
    catch (SomeException e)
    {
        // ...
    }
}

... although the syntax seems to be somewhat up for grabs.

[joycestick]

But isn't that more lines of code and still no type inference? There may be a way to use expression statements - I've not fully absorbed how they could be used effectively yet.

[canton7]

I imagine you could write var x = ... if you wanted to: the compiler's got all of the information it needs.

See how languages such as Ruby use them:

x = begin
  get_value
rescue e
  # ...
end

[bernd5]

Or improved lambdas:

Today you can write:

using System;

double x = new Func<double>(() =>{
    try
    {
        return 42;
    }
    catch (Exception e)
    {
        // ...
        throw;
    }
})();

But in the future (maybe csharp 10)
It could be simply:

using System;

double x = () =>{
    try
    {
        return 42;
    }
    catch (Exception e)
    {
        // ...
        throw;
    }
}();

[Richiban]

IFFEs are an awfully expensive way of doing this kind of thing though

[bernd5]

A "self calling lambda" needs never any heap allocation. It could be perfectly inlined.
But currently roslyn does implement this like all other lambdas with allocation overhead. That could be changed.
And we were talking about the syntax - not the actual implementation.

[bernd5]

See how efficiently it could be implemented: c++ implementation

It is actually compiled to:

mov     eax, 42
ret

[spydacarnage]

The issue with all the suggestions in this thread so far is that there is no emphasis on what happens to x when an exception is caused.
For instance:

try var x = GetValue();
catch (SomeException e)
{
    // deal with exception
}
// x is not defined at this point

[joycestick]

Thanks, @jnm2. This would definitely be something to point out if this discussion gets enough support to put this in as a proper proposal. Worth me editing this discussion as well do you think?

[spydacarnage]

The original, however, could be

double x = 0;
try ...

Whereas you lose that with:

try double x = ...

[smoothdeveloper]

I concur with @spydacarnage concern, it should give indication of using unassigned local in this case, using CS0165 error.

try var x = GetValue();
catch (SomeException e)
{
    // deal with exception
}
// if x is not assigned in the catch, or the catch is not throwing or returning:
// CS0165: use of unassigned local variable 'x'

So maybe:

var x =
  try => GetValue()
  catch (e) => ExceptionHandler(e).Then().GetValueWhenItFailed()
  // also need to think about finally...
;

This can't be an error since the catch is forced to return an expression of same type of the try branch (or it could be either throwing or returning altogether).

It is nice idea to have an alternative to try/catch being only a statement block and turning it into an expression.

There are other changes that made it to C#, like the switch expression or expression bodied members, so finding an approach which work with try/catch: 👍.

[jnm2]

@joycestick Only if you think other people will notice the same thing and miss this comment thread (or not even read down this far).

[joycestick]

@spydacarnage Yeah agreed. The situation where you want to preset a value before executing the try isn't something I'd originally intended on replacing. I'd just use the currently available syntax in that case.

Of course if you wanted to ensure x was initialised you could always make the proposed syntax of:

try var x = GetValue();

equivalent to:

InferredType x = default;
try
{
    x = GetValue();
}

but I think setting a variable to its default in this way should be explicitly the job of the developer in the catch block if that's what they want to happen.

[djthegr8]

Another possibility is, and this solely applies to the case where the exception caught is irrelevant, we could set x to null if an exception is thrown. A major throwback of this would be that a returned null would be the same as a thrown exception, plus you can't set a non-nullable type in this...

// GetValue does not throw an exception, x would be equal to whatever it should be
try var x = GetValue();
// ThrowValue throws an exception, and y is set to null
try var y = ThrowValue();

[HaloFour]

I'd suggest that if you're seeing that more than 1% of the time that something is glaringly wrong. Analyzers will typically flag such use of try/catch as inappropriate. If the language were to make it easier to write it would be tantamount to encouraging use of that pattern. In my opinion the verbosity (as little as it is) should remain if only to give the developer pause to consider whether that kind of exception handling is appropriate.

[djthegr8]

Makes sense... VS doesn't really mind this, and R# ensures that you write a comment as to why you're ignoring the Exception, so that's that...

[theunrepentantgeek]

it is pretty often that you see blocks of code like

Your experience differs widely from mine - I can't remember the last time I reviewed or wrote code that simply ignored an exception like that.

In fact, I'm pretty sure that any PR containing that would be promptly rejected with a comment instructing me to fix it.

I think @HaloFour sumarized it well - this is not a coding practice that should be encouraged, so the language shouldn't be making it easier to do.

[differentrain]

Your experience differs widely from mine - I can't remember the last time I reviewed or wrote code that simply ignored an exception like that.

In my experience, I have to write these code:
In library project, all exceptions will be thrown and handled, but in some UI project, these exceptions are "converted" to null.
So I like these code:

// GetValue does not throw an exception, x would be equal to whatever it should be
try var x = GetValue();
// ThrowValue throws an exception, and y is set to default value
try default y = ThrowValue();
// ThrowValue throws an exception, and this exception is thrown
try var z = ThrowValue();
catch (exception e)
{
  //todo
}

[theunrepentantgeek]

With due apologies for being slightly off topic ...

in some UI project, these exceptions are "converted" to null.

This reads as though you have applications that blithely discard any invalid user input without giving the user any opportunity to correct things. That sounds actively user hostile to me - and is an approach the language absolutely positively should not endorse by enshrining with specific syntax.

If you absolutely must have such a thing, you can easily achieve it with a simple helper method that you bring into scope with using status and use where required:

public static T Try<T>(Func<T> func, T fallback) 
{
    try
    {
        return func();
    }
    catch
    {
        return fallback;
    }
}

[gulshan]

Some prior discussion here- #2734