Discussion: throw_ret keyword or similar, cause calling function to return to simplify error handling and analysis functions

[johndv7]

edit: link to more refined version...turned into an evolution of exception handling
#9536 (comment)
#9536 (comment)

We use this pattern a lot:

 try {
    Foo1().ThrowOnError();
    Foo2().ThrowOnError();
    Foo3().ThrowOnError("This very bad thing happened")

    // this version checks return value against 42, the expected value, and returns Not42 if you don't get the expected value
    Foo4().ThrowOnError(42, Not42);

   // some extremely complicated analysis/error checking that throws if something really bad goes wrong
   // else returns something I can deal with here
   ret = ThrowIfAngry(listOfPoints, otherStuff...);
}
catch (Dv7Exception ex) { //the derived exception simply includes an error and a msg that can be extracted in the catch and/or logged
    
    //get error extracts the error if it's our own exception, or simply return UnexpectedException...
    ret = ex.GetError()

    // or maybe
    // ret = ex.GetError(log, LogType.Error, "Woops");
}

return ret;

Obviously these are often implemented as extension functions. I'll be happy to provide a working example, but I think you can imagine what we're doing. It's pretty simple, if not maybe a little abusive.

Basically, we have the situation a lot where we have a bunch of stuff we want to do, but if something fails we want to return the error. We find this pattern to be very expressive and very easy to read, but it still has the penalty of an exception. Maybe even more annoying, I have to wrap things in a try-catch and increase my indent level.

Even MORE annoying, is sometimes I have things that actually DO throw exceptions that I don't want to catch, so I can't even use this mechanism without writing even more code, making special exception types, etc.

What I really want to do is:

Foo1().RetOnError()
Foo2().RetOnError();
Foo3().RetOnError("This very bad thing happened")
Foo4().RetOnError(42, ErrorWhatever);

RetIfAngry(listOfPoints, otherStuff...);

return Ok;

I would love to have something like a throw_ret keyword. It would cause the CALLER of my function to return whatever value I return. So for example, it is currently implemented like this:

// just a couple of basic versions

public static void ThrowOnError(this CoreError e)
{
    if (e != CoreError.Ok) {
        throw new Dv7Exception(e);
    }
}

 public static void ThrowOnError<T>(this T e, T expected, CoreError thrownError)
 {
     if ((e != null && !e.Equals(expected)) || (e == null && expected != null)) {
             throw new Dv7Exception(thrownError, $"error = {e}");
    }
}

I'd love to be able to write it like this:

public static CoreError RetOnError(this CoreError e)
{
    if (e != CoreError.Ok) {
        throw_ret e;
    }
}

public static CoreError RetOnError(this CoreError e, Logger log, [CallerLineNumber] int line=0, [CallerFilePath] string path = ""))
{
    if (e != CoreError.Ok) {
        log.Log("A thing happened", line, path);
        throw_ret e;
    }
}
 public static T RetOnError<T>(this T e, T expected, CoreError ret)
 {
     if ((e != null && !e.Equals(expected)) || (e == null && expected != null)) {
         throw_ret ret;
    }
}

Perhaps it would make sense to decorate the return type somehow to make it clear that this is different:

public static throw_ret CoreError ThrowOnError(this CoreError e)
{
    if (e != CoreError.Ok) {
        throw_ret e;
    }
}

public static throw_ret T ThrowOnError<T>(this T e, T expected, CoreError ret)
{
     if ((e != null && !e.Equals(expected)) || (e == null && expected != null)) {
             throw_ret ret;
    }
}

//or maybe even something like this
// IMHO, this would be EXTREMELY powerful and useful.
public static throw_ret(CoreError) int ComplicatedFunction(lists, lists, andMoreLists)
{
    int a;
    int b;

    somethingReallBadHappened = DoABunchOfStuff(int a, int b);
    
    if (somethingReallyBadHappened) {
        throw_ret OhNoes;
    }
    return a + b;
}

// and even this
public static throw_ret(CoreError) CoreError ComplicatedFunction(lists, lists, andMoreLists)
{
    int a;
    int b;

    somethingReallBadHappened = DoABunchOfStuff(int a, int b);
    
    // the caller doesn't care about these errors...they really are errors and there's nothing to do
    if (somethingReallyBadHappened) {
        throw_ret OhNoes_GiveUp;
    }

    if (perfect)
        return JustRight;
    else
        return NotQuiteRight_FixIt;
}

//then I could do something like this, which just feels very simple and very powerful
{
CoreError ret;

    ret = ComplicatedFunction(lists, lists, andMore);

    if (ret != JustRight) {
        FixItUpABit();
    }

    DoMoreStuff();
    etc...

    return Ok;
}

Or something like that? I don't know, maybe throw_ret isn't a good name because it's not throwing anything? It was just the first thing that came to mind. I'd be happy with almost any name.

These are extremely simple cases. We find it very powerful to stick some of our more repetitive error checking, complex functions, etc into reusable blocks. It's not even necessarily for errors! Often times it's just an outcome....I analyzed the thing enough to know what the result is, so you can stop now and return the result. But it feels like we either have to do this kind of abusive (and ugly) ThrowOnError() thing we've concocted, or we have to litter very simple code with endless if-return statements.

I looked around but couldn't really find a similar proposal. I saw some for things like conditional returns, but what I would really find useful is to actually be able to call a function, It's not just syntactic sugar for when to return.

You can imagine how powerful it would be that you can have different classes that you can pick at runtime affect the logic of your software in such a simple way.

Thanks for reading! We've been casually thinking about this for maybe 2 or 3 years now, trying to figure out what we're actually asking for. We think the last version, where the throw_ret and normal return can be mixed just kind of feels right.

edit: changed to discussion. I misread the guidelines.

[siegfriedpammer]

Feels like you want a Result<T, TError> monad with built-in language support.

[CyrusNajmabadi]

I can't point to any specifically.

I'd be very wary of over-indexing on a particular approach you guys are using and extrapolating out to it being something that would be much more broadly useful and applicable to the larger ecosystem.

Because I don't want a Task. I just want a simple return type. I'm desperately trying to remove layers, not add more.

I'm not seeing how a task broadly adds layers. It's still a concept with specific syntax to produce and consume results (and exceptions) in a composable fashion.

Consider that we very much will not be amenable to adding an alternate way if doing things here if it's just reinventing what is already possible. Especially if it's just because you prefer saying Result<T> over Task<T>. :-)

[CyrusNajmabadi]

But ultimately, I just want a function I call to cause a return in my own function.

I feel like exceptions are the way to go. The primary complaint I've seen you levy is that these can then be caught by someone writing "catch". But I have no idea why that's a problem. Furthermore, I don't see how a new return type changes things.

If we're passing upwards some `Result<T,TError>, then customers can similarly end up intercepting those and completely drop them (or anything else you don't like).

I'm not understanding or seeing reasonable use cases and explanations why this new approach is beneficial :-)

[johndv7]

My primary "complaint" (though I'm not complaining...I'm making a suggestion) is all of the boiler plate I have to type for a very simple use case.

Just like adding the "field" keyword. There's nothing that added to the language other than eliminate boilerplate for a common use case and make the language simpler to use. And stuff like that is why I really like C#.

[CyrusNajmabadi]

is all of the boiler plate I have to type for a very simple use case.

I guess my main point is that I both don't really see what boilerplate you end up needing to write (exceptions are actually nice that way). Nor do I see what the core difference is here that makes using existing constructs not viable :-)

[DavidArno]

I'm still having an issue seeing what's wrong with exceptions.

There's nothing wrong with exceptions. However, with the power of pattern matching coupled with unions, it becomes simple to return the error state directly, rather than throwing an exception. The main benefit of this is that the error can be handled immediately, rather than later in the code within a catch block. This works really nicely with Rust for example. But Rust has the advantage of this feature being built into the language and framework from the start. Trying to retrofit such behaviour to .NET & C# is very unlikely worth the effort as the work would be huge and the benefits minimal.

[johndv7]

Based on what @siegfriedpammer said, maybe a workable idea is something like this:

-introduce a new kind of exception that doesn't get caught by catch
-introduce throw_ret and catch_ret keywords
-every function has a default catch_ret handler that does return exception.ret (assume the new exception type has a <T> ret member)

// where return type is `throw_ret<NormalReturnType, ThrowRetReturnType>
public throw_ret<int, MyErrorType> Foo()
{
    a = DoSomething();

    if (a is horrible)
        throw_ret OhNoes;

   return a;
}

void MyErrorType MyFunc()
{
    a = Foo();

    return Ok;
}

//or even
void MyErrorType MyFunc()
{
    try {
        a = Foo();
    }
    catch_ret (ret) {
         // you don't get to return me...I'll do something instead
         DoSomethingBasedOnRet(ret);
    }
}

The entire point being that catch and catch (Exception ex) isn't going to catch this new exception type, and if you don't explicitly do a `catch_ret', you just get the default behavior of return.

[HaloFour]

You've basically described a Result<T> monad, and there is some interest in supporting a way to "unwrap" them akin to how one awaits a Task<T>, except without the asynchronous state machine and coroutine overhead. Maybe something like this:

Result<object> DoLoadTest (object stuff)
{
    unwrap device.SetParameters(stuff);
    unwrap device.SelectLoad(stuff);
    unwrap device.TurnOn(stuff);
 
    unwrap device.TurnOff(stuff);
    unwrap device.GetTestResults(out tr);

    return Result.Ok();
}

[johndv7]

Yeah, @siegfriedpammer mentioned that, and drove me to the idea of integrating it fully with exception handling.

Honestly, I really had never hear of a monad before and I'm very not familiar with F#, but I tried to kind of understand the idea. I think one difference is that my idea would separate the concept of return type (from the function) and what the caller returns. So you could do this:
tr = GetTestResults();

instead of:
unwrap GetTestResults(out tr)

And thank you for engaging me in this kind of, somewhat, crazy idea. I get that it's a bit out there, but I also feel like there's something here...somewhere...that's not entirely crazy. Lol. :)

[HaloFour]

I wouldn't worry about the "monad" bit, all that matters is that you have a wrapper type that can indicate success or failure. Without language support you have to always interrogate that type to determine if the method call was successful and propagate the failure to the caller. Language support can automate that so that if the result is a failure that the failure gets propagated much in the same way an exception would. This is very similar to how await already works with Task<T>. But there would definitely be an expectation that the consuming method would explicitly opt-in to such behavior through some kind of syntax or operator, like await. There wouldn't be an implicit return from the calling method.

[theunrepentantgeek]

I once had some elegant code that achieved a sort-of similar result using a dedicated wrapper type to control the workflow. It worked something like this:

var test = deviceTest(device)
    .SetParameters(stuff)
    .SelectLoad(stuff)
    .TurnOn(stuff)
    .TurnOff(stuff);

return test.Result;

where the deviceTest() method returns a wrapper around device that exposes the same methods (by sharing a common interface). But, when an error occurs, the wrapper temporarily swallows it, and turns the remaining method calls into null operators (effectively short circuiting execution). The call to test.Result at the end extracts the error and returns it.

[theunrepentantgeek]

That said, I'd dearly love to be able to do something monad-like or monad-adjacent.

[HaloFour]

See:
#7488
#3403

IMO Task<T> and task-like types are already so close to encapsulating this behavior.

[johndv7]

So just talking out loud, and trying to bring this into sharp focus.

Currently, you throw a System.Exception.

Potentially, it could look like this:

class abstract ExceptionBase {
    //bunch of exception stuff
}

class Exception : ExceptionBase {
}

class ReturnException<T> : ExceptionBase {
    T ret;
}

where:
-catch only catches exceptions of type Exception
-catch (T ex) can catch anything of T = ExceptionBase, including ReturnException
-throw can throw anything of type Exception
-throw_ret only throws exceptions of type ReturnException (throw_ret Error can figure out Error's type from the function declaration)
-catch_ret is now unnecessary...you can simply catch(ExceptionBase ex) if you really want to catch everything
-catch_ret is still useful, though, because the compiler can type check your return type against the expected against the function signature of the called function, instead of providing an explicit T
-every function that calls something with a return type of throw_ret<T, T> has a catch(ReturnException ex) {return ex.ret;} handler
-functions that don't call anything that does throw_ret<T, T> are completely unchanged

So a lot of the feature ends up being syntactic sugar for something I could almost implement today.

[HaloFour]

Why are you trying to return an Exception type from a method that calls a method that throws that Exception type? What is the purpose of returning that Exception as a successful return value?

[johndv7]

And I don't disagree with you to some extent. I'm looking for a simple way to integrate this with what's currently there.

I would personally be happy with a simple thing that unconditionally returns a value, but I don't think it would be a good way to do it:

new_return_thing<int, returnType> MyFunc() {

   if (whatever)
       new_return_thing Bad; // or ok, or whatever
   else
      return 5;
}

This would make me happy for my particular use case, most of the time. But it feels like the exception handling mechanism already has this concept of "I'm breaking your flow...you're going where I say, unless you say otherwise", so I'm trying to stay within that concept.

So the more I though about it, and read some feedback, it started coming into sharper focus. There's always a tension between exceptions, your own flow, and things that you may want to return or otherwise handle. I want the compiler to help simplify this handling so that I can be more expressive with less distraction.

I'm suggesting that the language itself can add a feature to give us better control over this and basically handle the boilerplate for us for the really common case...but still give us control when/if we need it. And with the addition of a keyword, can do all of our type checking for us. It's all already there, I think.

So yes, you're very right. It's weird to return an "exception" as a good value, and maybe that just ends up being an anti-pattern that people recommend against, but this is why I amended my original post to indicate that in a broader sense, maybe I'm suggesting that Exception handling can evolve into something better and more complete.

But ultimately, I just want a function I call to cause a return in my own function. Or give me C style macros. LOL

[HaloFour]

but this is why I amended my original post to indicate that in a broader sense, maybe I'm suggesting that Exception handling can evolve into something better and more complete.

I don't see how this proposal makes it "more complete". It seems to imply that Exceptions should be used for non-exceptional cases, and that is definitely not something C# should be encouraging.

[johndv7]

Well, exceptions are already used everywhere in APIs for non-exceptional cases, and it's a bit of a pet peeve of mine.

And this is part of the tension between, say, return a value or throw vs pass a ref and return an error type. There's nothing in between.

Like, let me return the int that you're looking for if nothing goes wrong, but give me a shorthand so I can have you return the Error (or whatever) when appropriate. And let's do it without you having to setup a try-catch, or pass something as a ref and check for errors. And then I can still just throw when something truly exceptional happens, and if you don't catch it, it bubbles up.

Yes, it's no particular problem to simply keep typing in gobs and gobs of boiler plate try-catch and if-returns, but I feel like the language can do something really slick and usable here.

[CyrusNajmabadi]

My preference on that is to just use an actual value when you have something you want to return, or null if you don't. then you write things as:

var ret =
    device.SetParameters(stuff) ??
    device.SelectLoad(stuff) ??
    device.TurnOn(stuff) ??
    device.TurnOff(stuff) ??
    device.GetTestResults(out tr);

if  (ret != null) {
    return ret;
}

In the above you use exceptions for exceptional things. And you can still have a way to specify you have a value you want to shortcircuit and return once computed. You get brevity, while just needing one piece of explicitness in the code so the reader knows this is happening.

[johndv7]

Well, how about this:

-provide a way to apply a catch() to an entire block without the try (I'd be happy with just this)
-possibly even introduce a ?> operator, similar to a ? b : c but statement follows

-allow catch to accept rocket notation (maybe bad idea...not sure it would work as intended/expected but it is cool). Can live without. Put here for whimsy :) STUPID idea

-allow single statement catch (maybe even single statement try)

I think this actually personally gets me 95% of what I want, and may be useful to others.

Error Foo()
{
   // applies to the entire block
   catch (MySpecialException ex) { 
        return ex.ret 
    }

    // returns an int if successful, otherwise throws MySpecialException
    a = DoSomething();
}

// if I want to catch other exception
Error Foo()
{
   // applies to the entire block
   catch (MySpecialException ex) { 
        return ex.ret 
    }

    try {
        // returns an int if successful, otherwise throws MySpecialException
        a = DoSomething();
    }
    catch (Exception ex) {
        if (Exception is MySpecialException)
            throw;
    }
}

// using the notation I'm suggesting
Error Foo()
{
   // applies to the entire block. I think this would be cool
   catch (MySpecialException ex) return ex.ret;

    try {
        // returns an int if successful, otherwise throws MySpecialException
        a = DoSomething();

        // similar to `a ? b : c`  I've wished there was something like this for many years
        a > MAX ?> a = MAX;

        try Something() catch return Woops;
    }
    catch (Exception ex) {
        Exception is MySpecialException ?> throw;
    }
}

Pretty much doesn't change anything for anyone. It's just a bit of syntactic sugar.

[GabeSchaffer]

I think what you're looking for is called a "non-local return", where you have a return that returns from your caller instead of yourself. This is common in languages where blocks of code (like the statement in an if or foreach) are implemented as lambdas. So you may be able to write something like if (x) return y; but it's implemented more like if (x) () => {return y;}(), which isn't useful unless you can make the return y actually return from the function executing the if instead of just returning from the lambda.

One way to implement this is with exceptions, where the non-local return throws a special exception, and the caller catches it, turning that into a return. I think you're asking for some syntactic sugar to make your implementation of this easier. Scala took this route (although their first attempt was deprecated, the new is similar).

Another way to implement this is for the compiler to inline the function, such that a return (or break or continue) executes in the context of the caller. Kotlin uses this mechanism. I think this is the kind of solution you actually want, and it would solve this problem, too: #9512,

[CyrusNajmabadi]

It does not capture the specific error,

How so? They return null on no error. Or a specific value on an error. You then decide to do whatever you want to do when one fails.

[CyrusNajmabadi]

It's why I started this discussion.

A core problem I'm having is that I haven't seen an example that demonstrates the problem effectively. All the cars so far have been trivial, and easy to write with existing idioms. So I'm finding it hard to figure out what actually needs solving, meet alone what an appropriate solution would even look like :-)

[johndv7]

I phrased it poorly. In that particular case, it works OK, assuming I'm OK with null == no error (which I personally find very ugly...why should null == NoError? ...sometimes?)

In this case, it fails completely:

    a = device.GetSomething();

Now, my only option is throw-catch(MyException ex) { return ex.ret }

or

    ret = device.GetSomething(out a);
    if (ret != OK)
        return ret;

and when there's a mix, it's a mess. Totally doable, and you just do it, but it's a lot of code to capture a simple idea.

[CyrusNajmabadi]

which I personally find very ugly...why should null == NoError

Because it returns a value indicating something went wrong. If nothing went wrong, there is no value. So null.

In this case, it fails completely

I'm not seeing why is fails there.

[GabeSchaffer]

I like the idea of implementing it via exceptions

I don't like the idea of using exceptions for dealing with common conditions. Even if you tell the debugger to not break on a specific type of exception, the debugger still has to be notified and communicate with the attached process to determine that it's just going to let the process keep running. This can make it painfully slow to debug a process that uses exceptions this way.

While you may not intend to use the feature in this way, others certainly will. Some Python code has this problem.

I prefer the Kotlin solution because it could potentially allow anything that you can't currently do to a function's caller, like allocate stack memory, goto, continue, break, or return. I wish for this feature every time I try to factor out some code, but can't because it has a return or break in it.

[CyrusNajmabadi]

Having read the thread a few times now, I'm realizing that this proposal is lacking some realistic, valuable, examples.

I think these are necessary so that we can:

1. See real cases where the problem arises.
2. See if current solutions are viable or not for addressing those problems.
3. See if the proposed solution actually solves things.

Right now I'm caught by 1 and 2. The examples are not compelling currently since they're so vague and basic, and the examples given have simple solutions with existing language constructs. As such, there isn't motivation to even consider adding something new to the language.

[johndv7]

Well, I'm kind of stuck that I can't just cut and paste code here, because rules/IP/etc, and even if I could I've worked around the issue in many ways that it's not obvious what the complications are, because we've worked very hard to bury it. I wouldn't even know how to start to explain that.

So I'm trying really hard to come up with simple use cases that are easy to understand but capture the essence of what's causing me grief, and hoping that other people get why it's painful at scale.

I appreciate your feedback, and I'll try harder to find a "real" case that might resonate.

[CyrusNajmabadi]

I wouldn't even know how to start to explain that.

I think it is important here to have these examples demonstrating why all the existing patterns and techniques don't work:-)

So I'm trying really hard to come up with simple use cases that are easy to understand but capture the essence of what's causing me grief, and hoping that other people get why it's painful at scale.

Tbh, I think it's doing you a disservice. The examples are so generic and out of the norm. You're validating arguments, but avoiding exceptions. You want to return values, but won't use 'null' to indicate you have no value to return.

A lot of the place you're in feels a bit self inflicted to me :-)

I appreciate your feedback, and I'll try harder to find a "real" case that might resonate.

Thanks! I look forward to reading that!