Proposal: Per statement exception handling support (trycatch)

[DavesApps]

Statement level exception handling for simpler per statement error handling

Before exception handling you had things like global variables to return error values or just error return codes. They were bad and ugly but, you could easily and specifically check the line of code that failed by checking the return code. Though it was tedious, you knew the line of code that failed and could act on it.
After exception handling came to be, often the code blocks for try/catch are too big to know specifically which line failed or you are left to wrap individual functions in a try catch block, or add Booleans /check other return values to see how far into the try block it got, that adds a lot of mess/typing.

Per statement exception handling could give you close to the best of both worlds, when needed, old style relatively succinct per statement error/exception control while still allowing larger try/catch blocks.

Old way pseudo code:

If (!Functioncall1())
{
Int error= GetLastError();
// use error value.
}

If (!Functioncall2())
{
Int error= GetLastError();
// use error value.
}

Of course this would get pretty messy if you had a lot of function calls to check in a row but you could precisely handle the error per statement with less boiler plate code than try/catch.

Now to do the same with try/catch exception handling you might need to do something like the following to catch exceptions per function call:

Try
{
Functioncall1();
{
catch(Exception e)
{
   //Handle  exception Functioncall1
}
Try
{
Functioncall2();
{
catch(Exception e)
{
   //Handle  exception Functioncall2
}

We could have called Functioncall1() and Functioncall2() within the same try/catch block but then we wouldn’t know which function was at fault without using either the stack trace to figure it out somehow or Booleans like most folks use to see if functioncall1() completed or not.

That’s pretty wordy and messy. Old style actually is a little cleaner (well not the global variables part)… but we can’t easily do single statement exception handling without the wordy try/catch code blocks around everything. Wouldn’t it be great if sometimes we could handle errors/exceptions the at the statement level also? Its at least a little less wordy than with current exception handling syntax when you need to know exactly which statement in a block threw an exception.

A possible better option for discussion:

Example:

If ( trycatch(Functioncall1()).Exception!=null)
{
// handle error here
}

What happened here?
What if that when you use with trycatch it wrapped the return value into a tuple and returning the original value plus adding Exception with the exception to the tuple which would be null if there was no exception.

Example:

 int Functioncall1() {...} 


If ( trycatch(Functioncall1() ).exception!=null)
{
// handle error here
}

Compiler translates into roughly

(int retVal, Exception exception) AnyonymousFunction1(statment)
{
   exception=null;
  Try
  {
   retVal={statement}
   }
   catch(Exception e)
   {
     exception=e;
   }
   return (retVal,e);
}

If ((AnyonymousFunction1 () ).exception!=null)
{
// handle error here
}

This similar code size and flexibility of old style error handling with new exception handling. The downside is that exceptions still are more costly than the old style error handling in terms of performance. The ultimate solution would be the exception cost (finalization) would be avoided in this case since we've caught without a rethrow. though that may be too much to ask for. (Or perhaps there should be some type of rethrow option to offer complete support.)

Updated - avoiding the need for Try functions. Also possible performance optimizations:
As others have noted in other discussions something like this may prevent the need for the creation of all sorts of Try methods like Parse/TryParse if it's implemented efficiently. One of the keys though is performance is often desired also for the reason to use TryParse like methods, so if there was a way to optimize the exception performance (perhaps get rid of the finalization creation/finalization process for an exception for the methods called -i.e. LiteException) when an exception is returned this way.

This could even go as far as the compiler recreating the entire call chain of functions that could throw exceptions and instead of throwing return the exception as the tuple all the way up the chain to avoid performance and debuggability concerns. Basically solving the problem of sometimes needing to avoid exceptions on ANY API because of performance reasons. As has been mentioned sometimes its hard to tell when writing an API could be a performance concern if it threw exceptions as it is often usage that decides that. Something like this could provide the best of both worlds exception handling or individual error handling to avoid performance/debuggability concerns as needed.

Updated - Possible way to avoid swallowing exceptions that are not yours:

If ( trycatch<InvalidOperationException>(Functioncall1()).Exception!=null)
{
// handle error here
  // support a rethrow here somehow perhaps ? probably need some different syntax.
}

This proposal unlike many of the others previously proposed does not necessarily hide the exception, it is returned or still thrown. Perhaps this is a safer alternative?

This proposal may handle many of the cases folks are concerned about:

• tighter/reduced syntax and readability
• debuggability - by turning exceptions into return values
• Performance improvements by turning exceptions into return values.
• Doesn't hide exceptions you don't want to catch, they are available to use or throw

[HaloFour]

Your syntax seems to completely ignore the possibility of return values. This is also functionality that you could very easily achieve through a library function:

public static class Utilities {
    public static (T value, Exception exception) TryCatch(Func<T> func) {
        try {
            return (func(), null);
        }
        catch (Exception exception) {
            return (default, exception);
        }
    }
}

static class Program {
    static void Main() {
        if (Utilities.TryCatch(() => SomeFunction()).Exception != null) {
            // handle error here
        }
    }
}

[DavesApps]

@HaloFour yep you wrote the code I prototyped this idea with :) I just thought there would be a little less typing if it were a keyword. I agree with return values there is a little extra code to write. I like the library function though in lieu of getting this as a keyword. (So maybe not worth it if folks are ok with needing to have a library function and a lambda expression.)

Updated: Also though one of the reasons people use Try functions like TryParse is to avoid the exception overhead, it would be nice if there could be some compiler optimizations to reduce the exception overhead as something like this could then perhaps nearly eliminate the need to keep creating two types of methods like Parse and TryParse.

[jnm2]

After all the discussions everyone has had about the issues with swallowing exceptions that you don't own and preventing the higher-up actually responsible caller from reasoning about how to react, @KrzysztofCwalina is now pushing for this so I'm just going to save my energy for the time being and link this list of previous discussions. https://github.com/dotnet/corefx/issues/19928#issuecomment-331976206

[DavesApps]

@jnm2 interesting reference, thanks.

I was thinking if we are worried about swallowing exceptions we shouldn't (I agree that sounds bad), syntax could be like

If ( trycatch<InvalidOperationException>(Functioncall1()).Exception!=null)
{
// handle error here
  // support a rethrow here somehow perhaps ? probably need some different syntax.
}

It would only catch the specified exception... perhaps could allow a list of exceptions.

[DavesApps]

Copying some info that got put into the wrong thread: #980

This proposal #965 offers a suggestion that the implementation could be instead of throwing exceptions when a function is wrapped by trycatch it would be recompiled to RETURN the exception rather than throwing it, to avoid the performance overhead of the exception. So basically it does rewrite a method to some extent. It won't be as good as a custom one but in theory during recompile of a method it could disable finalization options for the exception which should significantly improve the performance of the create and clean up.

When it's jitted it could just replace return values with the tuple and replace throw with return the tuple. Jit happens on all methods at runtime. It should be a relatively simple replacement/addition of the IL to Jit during generation. (It was just a suggestion at solving this ubiquitous problem that lots of people are asking for all different sorts of methods with Try on it to avoid exceptions... Any other ideas that could solve having to write regular methods and Try methods all the time?) Seems like enough folks run into this once in a while would be nice if we could find a general solution.

Yes this could mean it has to go a couple levels deep for the method to try to optimize exception usage. Perhaps there are options or defaults that can be set on it. The JIT could rewrite all methods if needed to catch exceptions, even system libraries or for size limitations perhaps could have a limitation to X levels deep for optimization.

I realize that sounds pretty intense