Allow => everywhere

[banjouuid]

It could be nice to have:

try => FilePicker.Open(file); catch=> Debug.WriteLine("error");

Rather than:

try { FilePicker.Open(file); } catch { Debug.WriteLine("error"); }

Let me know what you think.

[Vlad-Stryapko]

I'm a huge fan of => but it doesn't really look good in this particular case. It makes me think try and catch are semantically disconnected from one another.

[iam3yal]

@Vlad-Stryapko It should probably be something like this:

try => FilePicker.Open(file) catch => Debug.WriteLine("error");

But honestly, the following looks much better:

try FilePicker.Open(file) catch Debug.WriteLine("error");

I can't see the benefit of having the arrow there but maybe for something like this:

try FilePicker.Open(file) 
catch(IOException) => Debug.WriteLine("error");
catch(Exception) => Debug.WriteLine("error");

Again, don't think it looks that good and we go back to the point of making swallowing exceptions easier, this topic was discussed to death though.

[HaloFour]

What about catch blocks that handle specific exceptions? What about multiple catch blocks? I don't see how the => syntax deals with the issue of ambiguity of correlating catch blocks with nested try blocks:

try =>
try => DoSomething()
catch (FooException e) => HandleFooException(e)
catch (BarException e) => HandleBarException(e) // where do I belong?
catch (BazException e) => HandleBazException(e) // where do I belong?
finally => CleanUp() // where do I belong?

Also, your proposal title is "Allow => everywhere" but you only touch on try/catch blocks. => isn't allowed in most control statements.

[iam3yal]

@HaloFour Well, by disallowing nested exception you avoid the issue completely so in my opinion it make sense to disallow it.

Alternatively:

try => (try => DoSomething()
        catch (FooException e) => HandleFooException(e)
        catch (BarException e) => HandleBarException(e)) 
catch (BazException e) => HandleBazException(e)
finally => CleanUp()

[banjouuid]

The point in here is to make code more readable, if we can make it from {} to => and from => to not having anything at all as @eyalsk suggests try FilePicker.Open(file) catch Debug.WriteLine("error"); would be brilliant too

[alrz]

try =>
try =>

try is not an expression, I suppose the grammar is try => expression

[CyrusNajmabadi]

The problem with this is that => means one of two things depending on context. It either means { expr; } or it means { return expr; }. That's why it can be easily used with lambdas, methods, constructors, etc. it's known from context which of those forms is meant.

With statement forms, it isn't clear. if i have:

int Foo()
{
    try => Bar();
    catch => Baz();
    return Quux();
}

Does that mean:

int Foo()
{
    try { return Bar(); }
    catch { return Baz(); }
    return Quux();
}

or

int Foo()
{
    try { Bar(); }
    catch { Baz(); }
    return Quux();
}

?

[MkazemAkhgary]

Well at the end of the day it saved only two characters.

[yaakov-h]

One.

[iam3yal]

The only proposal that I really want that yes, saves on characters and nesting is the namespace one but most of these niche proposals just don't cut it for me and probably for many of us.

p.s. Just think of the times you have to catch an exception and even more so the time you spend calling a single method in a try/catch block, does this really worth a language change? or anything?

[magol]

I suggest following pattern

Foo() catch (IOException) Debug.WriteLine("error");

This pattern is restricted to only one catch.

[yaakov-h]

I'm not so sure that swallowing exceptions should be made easier...

[NN---]

@banjouuid This is useful only if try..catch becomes an expression, but then a question whether => is really required.

int a = try int.Parse(input) catch 0;