Feature: 'Safe' methods that guarantee won't throw exception

[DouglasHammon]

Hi,

Often I need to write code where I'm coordinating with multiple external systems (micro-service, queue, email service, payment processing, etc..) in a single unit of work. The code needs to be written in such a way as to prevent an unhandled exception from terminating the execution of process (E.g. I just processed a payment, but now I did to mark the order as 'paid' and it that fails, roll back the payment). It is common when writing this type of process that distributed transactions are not possible.

When writing this code, I will prefix a method name with "Try" to indicate that it won't throw. The implementation of this method wraps its code in a try/catch block.

It would be nice to have a language feature where I could mark a method as being safe (won't throw unhandled exception). This marker could be a [Try] attribute or a keyword similar to async and Task (try keyword with Try result). This attribute/keyword will at compile time wrap the implementation of the method with a try/catch block.

This would eliminate the boiler plate code to wrap these methods in a try/catch block.

What do you think?

[svick]

What would the catch block do with the exception? Ignore it?

And what about exceptions that cannot be caught?

[DouglasHammon]

What would the catch block do with the exception? Ignore it?

The exception would be returned to the calling method. The return type of the method would be would be something like:
public class Try<T> { public T Result {get; set;} public Exception Exception {get; set;} }

And what about exceptions that cannot be caught?

Then it would throw. The try/catch block I normally write would not help in this case either.

[GrabYourPitchforks]

Sounds almost like a constrained execution region in terms of the scenario. But even CERs didn't swallow exceptions, as swallowing exceptions is generally a discouraged pattern since it masks what could very well be a legitimate problem which requires correction. CERs were instead a contract by which a method could be annotated as "I promise not to do anything that could throw a synchronous exception." Out-of-band exceptions (memory corruption or other externalities which we can't account for) could still be fatal to the process.

@DouglasHammon What about the scenario where the process itself simply dies or there's a power outage? Does your backend system still need to be resilient against this possibility? And if so, how would the proposed new language feature simplify matters?

[HaloFour]

When writing this code, I will prefix a method name with "Try" to indicate that it won't throw. The implementation of this method wraps its code in a try/catch block.

You mean that it can throw, but you'd rather ignore the exception than do anything with it. And that sounds like a really bad pattern to bake into the language or encourage other developers to follow. In these cases bubbling up that something went wrong to the microservice consumer or message queue sounds like exactly what you should be doing.

[ronnygunawan]

This requires static analysis for throws and try blocks.

[Vlad-Stryapko]

@HaloFour
TrySomething methods have been around in .NET for a while and I personally don't see anything bad about their appropriate usage.

I don't think declaring that a method doesn't throw an exception encourages you to write such methods. If anything, it's just more of a 'statically typed documentation', which I'm a big fan of.

Edit: I've reread the proposal and noticed it includes compiler automatically generating try-catch. That I don't approve for sure.

[HaloFour]

@Vlad-Stryapko

TrySomething methods have been around in .NET for a while and I personally don't see anything bad about their appropriate usage.

I agree, appropriate usage, whcih shouldn't be so common that it's onerous to handle exceptions within such methods. Although the BCL methods like int.TryParse don't generally deal with catching exceptions, they have a gracefully degrading parser. If that parser had a bug and were to throw that would bubble up to the caller.

[Vlad-Stryapko]

Precisely, I certainly disagree with OP regarding automatic generation. I initially assumed the proposal was about something similar to Pure attribute from Contracts, which is IMO a good thing to have.

[GeraudFabien]

TryParse work because :
1 - it's a very simple (quick. You can think of it as an atomic operation)
2 - you can easily analyse what when wrong because it didn't evolve a lot of factor.
3 - you have to do this a lot in your application. And you care a lot about it success or failure.

Even for a transaction i wouldn't recommend to just ignore the exception.

Let's just suppose i agree with you. In my pov i wan't the caller to ignore exception not the method itself. You're method as to do a job and do it right. It is job to throw exception. The caller has the job either to handle them or to send them back to they're own caller.

If you wan't to swallow handle

public bool TryF(Action action){ 
   try { 
      action();
      return true; 
   catch (Exception e) {
      // myAwesomeLogger.WriteError(e, "Some error was swallow")
      return false;
   }
  }

You can also make some neat override.

public bool TryF(Function<bool> action, [CallerMemberName] string additionalComment = null){ 
   try { 
      if(action()){
         return true;
      } else {
         // myAwesomeLogger.WriteError("Some method failed gracefully :" + additionalComment)
         return false;
      } 
   catch (Exception e) {
      // myAwesomeLogger.WriteError(e, "Some error was swallow")
      return false;
   }
  }

[DouglasHammon]

@HaloFour , @GrabYourPitchforks The intent is not to ignore the exception. If the method throws, the exception is returned and the calling method can decided what to do with it (log it, etc..). See the proposed return type here: #2866 (comment)

[HaloFour]

@DouglasHammon

So why not use a Try<T> monad? We don't need a language feature for this:

https://github.com/StephenCleary/Try

[ronnygunawan]

@DouglasHammon from my understanding, what you need is a static analysis for exception handling. Methods need to be analyzed for:

1. All possible exception types thrown from it
2. Whether the method will be invoked by framework and any uncaught exception should produce warning (flagged with [Safe] attribute)

[DouglasHammon]

@HaloFour Cool. Was not aware of that library. I'll check it out.

[liamlim]

I think that something like C++ noexcept keyword is a better idea. Noexcept method can call only noexcept methods and can't contain throw statement. Of course StackOverflowException still can be thrown but the noexcept feature at least guarantees that the method does something which is safe.

[FiniteReality]

Noexcept method can call only noexcept methods and can't contain throw statement.

This is not true:

#include <iostream>
#include <exception>

int x() noexcept
{
    throw std::runtime_error("oh no");
}

int main()
{
    int thing = x();
    
    std::cout << "thing == " << thing << "\n";
}

This is valid C++ code. Admittedly, the compiler will likely cause a warning that the noexcept function will always call terminate().

What the noexcept specifier actually does is cause the program to terminate when an unhandled exception is thrown in a function which is marked with it. It's like checked exceptions, except more flexible. It is intended to be used with the noexcept operator to check (at compile time) whether the given expression may throw or not. This can then unlock certain optimizations, e.g. using a non-throwing move constructor instead of calling a copy constructor in a std::vector.