Proposal: Exception coalescing operator (?!:)

[MattLebrao]

In the spirit of the extremely useful null coalescing operator, it could be a really useful feature to handle expected exceptions inline when evaluating expressions.

Pattern:

(expression) ?! (ExceptionType) : (defaultValue)

Where the expression can be a property being read or a non-void method.

Consider the following Example class:

class Example
{
    public object ExampleProperty => throw new NotImplementedException();
    public object GetExampleObject() => throw new NotImplementedException();
    public Example() { }
}

Then a few examples of the operator's usage:

var ex = new Example();
Example ex2 = null; 
var var1 = ex.ExampleProperty ?! NotImplementedException : new Object();
//or
var var2 = ex.GetExampleObject() ?! NotImplementedException : new Object();

//This line still throws a NullReferenceException, because that's not the type we meant to catch (and were expecting):
var var3 = ex2.ExampleProperty ?! NotImplementedException : new Object();


//But this line works, because we don't care about the specific exception type:
var var4 = ex2.ExampleProperty ?! Exception : new Object();

//The default Exception type could also be implied, meaning the next line is the same as above:
var var4 = ex2.ExampleProperty ?!: new Object();

In many scenarios we are aware and expect exceptions to be thrown from a single expression. Be it a method's return value being assigned to a variable and throwing an exception or a a property getter doing the same, dealing with expected exceptions inline have the advantages of improved code readability, as we won't have to create a try..catch block for a single line of code. It will also prevent creating aesthetically (readable) appealing try..catch blocks by wrapping more code then we expect to be throwing an exception (such as the lines around it, or the full-body of the current scope), which could cause the accidental catch of an unexpected exception at a different line and become a debugging hassle.

[colejohnson66]

Exceptions are meant to be exceptional. You should not be catching them where they happen, but further up the stack where you can report a failure condition to the user.

[MattLebrao]

I understand that, but there are cases when we know an exception means nothing exceptional. For instance, if I know a class partly implements an interface, I can expect some of the interface members to throw a NotImplementedException. Through the .NET documentation we can find numerous examples where exceptions are the expected behaviour for unideal cases, cases where the state of an object has become invalid for the operation but that this state change in itself is expected.
Which is also why making it possible to handle them inline on a nearly one-to-one basis would be ideal for cases where exceptions aren't exceptional, being an expected behaviour instead, and preventing blocks that might break readability or the case when the try block contains more lines than it should and an actual unexpected exception might get accidentally caught.

[huoyaoyuan]

For instance, if I know a class partly implements an interface, I can expect some of the interface members to throw a NotImplementedException.

Cases following this pattern are typically having CanXXX properties for checking before calling the members.

cases where the state of an object has become invalid for the operation but that this state change in itself is expected.

Calling invalid method for certain state is certainly a bug of caller.

Which is also why making it possible to handle them inline on a nearly one-to-one basis would be ideal for cases where exceptions aren't exceptional, being an expected behaviour instead

The only cases where exceptions are expected should be IO.

[KennethHoff]

We should not waste time on exception handling. It's an awful paradigm that we should move away from. What we should do however is make it easier to handle error states by improving pattern matching and optional types

[MattLebrao]

Personally, my view tends to steer away from anything that might make type enforcement weaker, as this makes the code more runtime-error prone. But I get what you mean, it's a valid point of view too, and can indeed improve the language if done carefully. The world doesn't need another Java.

[HaloFour]

IMO it should be pretty rare to want to catch an exception and ignore it, to the extent that I don't think the language should make it easier. It should stand out in the code and require a deal of friction to force the developer intent.

[huoyaoyuan]

On Error Resume Next again