Proposal: Add syntax support for returning a default value from a method if an exception is thrown

[trbenning]

Consider this code:

string value;
try
{
    value = GetValue();
}
catch(Exception ex)
{
    Console.WriteLine("Exception thrown!");
    value = null;
}
Console.WriteLine(value);

It would be nice if we could reduce the footprint with some syntax sugar, similar to how null coalescing operators work. Something like:

var value = GetValue() !? null : ex => Console.WriteLine("Exception thrown!");
Console.WriteLine(value);

[jjvanzon]

I disagree with this proposal, because as a general rule I say: do not derive information from the fact that an exception is thrown. Let exceptions be what they are: a break from the normal flow. If you need information that something is not filled in, call upon functionality that just tells you it is empty. Also: try and finally perform fine, but catch can have a performance impact if it goes off. Also you might be ignoring a different error than intended. You probably really want to know that your value is empty. But this code might hide other problems. So it promotes error hiding, so instead of a clear exception message it goes wrong and just continues. No error message and the customer finds out something is wrong, before the programmer can and the programmer spends hours and hours finding your bug, which should have been prevented by just letting the exception go off, not ignoring it. Exceptions are not our enemy. Exceptions are our friends. Don't write code to simply ignore them. I feel your proposal would promote these bad practices.

[trbenning]

@janjoostvanzon That's a fair point, and I can definitely see how this could be abused. That being said, there are plenty of times where exceptions are unavoidable (networking issues, 3rd party libraries, etc.), and your use case involves setting a default or cached value & moving on. Additionally, this proposal doesn't necessarily ignore exceptions, as it provides a mechanism to do something useful with it.

What if we could structure the syntax in a way that allows for catching specific exception types, and doesn't force you to catch Exception? Maybe something like:

var value = GetValue() !? null
    : SomeExpectedException ex => Console.WriteLine("This exception is fine.")
    : Exception ex => throw;

[jnm2]

Please do not ever do this.
The discussion on #220 and dotnet/roslyn#16072 applies. (Possible dupe?)

[jjvanzon]

@trbenning
I would like to give you some pointers for how you can better handle those situations where you think you need to catch that error. But I do not have the energy to spend much time at it right now. So excuse me if I am not subtle here.

In short: Be strict in code: either everything should go right, or the intermediate result should be discarded, show user vague error, log complete error for yourself. Analyse the error, solve the core of the problem.

• Network bad? Fix the network.
• Call the party giving you bad service connections. If they cannot solve the problem ditch them and move on.
• Handle network errors / database connection errors centrally with a single error handler.
• Work transactionnally, if not with the database connection then by producing new copy of the data that only replaces the original only if all went well.
• The main error handler should log it, intermediate results should be discarded. Original data should remain untouched.
• Look for functions that will give you the information as a bool, or null or otherwise telling you to skip something or default something and only skip it if it functionally makes sense, otherwise throw an exception and let it be taken care of by the main error handler.
• Yes, actually throw exceptions yourself and let the main error handler go off in bad situations.
• Get rid of bad third party library.
• OR: Keep the third party library and use their error message to learn how to use it correctly. It may actually be telling you, you're using it wrong.
• The cases where catching an exception are rare and should stand out and should be well commented, so they do not need a syntax for being more tollerant towards exceptions.

I would like to go into this a little more constructively, but see first paragraph.

[svick]

I really don't like the proposed syntax.

GetValue() ?? null : ex => Console.WriteLine("Exception thrown!")

To me, this reads something like:

If GetValue() returns null, the value is null, if it throws an exception instead, execute Console.WriteLine.

[MgSam]

You can do this with a library function.

/// <summary>
/// Tries to get a value from the given function. If it throws an exception of the given type,
/// it is caught and null is returned. An optional exception logic function is also run.
/// </summary>
/// <typeparam name="TException">The type of the exception to catch.</typeparam>
/// <typeparam name="TReturn">The return type expected.</typeparam>
/// <param name="function">The function to try and get a return value from.</param>
/// <param name="exceptionLogic">The exception logic to optionally run.</param>
/// <returns>The value from the given function, or the type's default value.</returns>
[DebuggerNonUserCode]
public static TReturn TryGetValue<TException, TReturn>(
    Func<TReturn> function,
    Action<TException> exceptionLogic = null
)
    where TException : Exception
{
    try
    {
        return function();
    }
    catch (TException e)
    {
        exceptionLogic?.Invoke(e);
        return default(TReturn);
    }
}

Usage:

var a = TryGetValue(() => SomethingThatMightThrow(), e => LogException(e));

[trbenning]

@svick I agree. Using ?? would be confusing. Maybe something like !??

I've edited my examples to use this alternative operator.

[aluanhaddad]

Perhaps it would be best just to omit the try. That would be safer and even more concise.

[DavesApps]

Similar proposal here that may have some benefits:
#965

• Doesn't hide the exceptions.
• Also discusses if there is compiler optimizations that could be done so that it would prevent the need for writing methods like TryParse for performance reasons.

[VBAndCs]

it is better to be:
value = try (GetValue( ), null);
try returns the value of expr1 if it succeeded, or retirns the value of expr2 if expr1 throws exception)

[CyrusNajmabadi]

This is highly unlikely to be something the language adds. Catching and ignoring all exceptions is an anti-pattern, and generally indicates some pretty significant design problems. The language shouldn't really be encouraging this.

[ufcpp]

Expected<T> in #147 ?