Allow omitting Exception suffix from exception type name

[BalassaMarton]

This could greatly improve code clarity. Like how we can write [Required] instead of [RequiredAttribute], how about working with exceptions like this:

try {
    // ...
    throw new ArgumentNull("someArgument");
}
catch (ArgumentNull e) {
    // e is ArgumentNullException
}

The compiler should allow omitting the Exception suffix in throw and catch expressions.

[miloush]

Sorry, having browser issues... did GitHub stop working in Edge?

I claimed this might break existing code, but wanted to clarify that not necessarily if existing types are prioritized which I believe is what happens with attributes.

However, would you expect this to be only after throw and catch or anywhere in the code?

[Thaina]

However, would you expect this to be only after throw and catch or anywhere in the code?

I don't support (but also not against) this feature. But I think this is acceptable as context sensitive limit

[miloush]

@Thaina The problem is when you limit it to the context then you get inconsistencies.

catch (Argument ae)
{
    if (e is ArgumentNullException ane) { }
}

If you limit it to the whole block, then some if blocks in your code can use ArgumentNull while others have to spell it fully. Also you can get into weird situations like exception variables coming from outer scope:

ArgumentException e;
try { }
catch
{
  if (e is ArgumentNull) { ... } // ?
}

What I remember when I was suggesting that the autocompletion list should only contain exceptions after catch is that as you can imagine, other things can be thrown other than exceptions in CLR and mixing this optional suffix in feels like only confusing things more.

Besides, I am not convinced that catch (Argument) { } and catch (System) { } makes much of grammatical sense.

[DavidArno]

Besides, I am not convinced that catch (Argument) { } and catch (System) { } makes much of grammatical sense.

I generally like this idea as the smurf-naming convention of sticking Exception on the end of every exception is ugly. But as ArgumentException and SystemException demonstrate here, not all exception names make sense without the Exception suffix.

With hindsight, exceptions should not have had Exception appended to them and the names should make sense as an error without that suffix. But we are where we are; they do have that suffix. As I say, I like this proposal, but suspect the negatives around conflicting names, badly structured names etc outweigh the gains of more elegant code.

[Thaina]

@DavidArno I am thinking in the opposite. Just like Attribute that could be optionally omitted. We can still put word Attribute when we think some name was too short to make sense. But whenever the name is long enough we can remove Attribute on it

@miloush I think it should be like that

catch (Argument ae)
{
    if (e is ArgumentNullException ane) { }
}

It make more obvious that we allow shorthand only in specific context. Same as Attribute that we require full name within the block of code outside attribute syntax

[BalassaMarton]

Yes I mean this to be limited to catch and throw (like how you can only omit Attribute in attribute usages, but not anywhere else). This is an optional language feature, so you can still throw and catch ArgumentException and others by their full name.