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

[johndv7]

edit: link to more refined versions...turned into an evolution of exception handling...then shifted to a conditional operator
#9536 (comment)
#9536 (comment)
#9536 (reply in thread)

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,

[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.

[martin-steinhoefer]

@johndv7
If your'e really into non-local returns, then create your own exceptions (let's say ReturnException - for 'void' returns and ReturnException<T> - which could return a value), throw them accordingly, catch them layers up and handle them to execute your program flow. That would perfectly work within lambdas too.

But be aware, that seems not wise, because

• performance penalty (exception handling is far more expensive than a return value
• you have only one exception 'in-flight' at a time per thread (be careful when actual exceptions happen)
• your program flow becomes very complicated - it would become a nightmare to understand/maintain (you could have a void-method throwing a ReturnException<T> which actually turns it into a T-returning function - that is mildly said irritating)

That is surely nothing, the language will encourage with special syntax making it convenient.

[johndv7]

@martin-steinhoefer
That's kind of what we do now with the whole "ThrowOnError" pattern. We're not super thrilled about it. We DO use exceptions, but we tend to use them for what they were originally designed for, i.e. something's broken, you've made a programming error, or some other horrible thing has happened. So it for sure makes us uncomfortable to use it the way we're using it, but we accept it because it makes the code so much easier to read.

So I'm exploring different ideas to get the same kind of ergonomics with some other construct that more designed to do 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.

[martin-steinhoefer]

Thank you for sharing your thoughts.

I use the term 'DSL' for 'domain specific language'. That strictly speaking stands for a 'programming language' specific to a certain domain like R for statistical problems or gherkin for tests.
But with a more relaxed point of view things like FluentAssertions (a framework to write assertions in tests) also introduce kind of a domain specific language - they provide you with a specific way to express assertions (extensible, flexible) by providing it's own way to use syntactic possibilities of C# to express the special needs of the problem domain (assertions).
One can even create it's own programming language (interpreted or compiled - maybe even to C#) that satisfies the needs of the problem domain.
Maybe you could benefit from having a framework (or a programming language) that supports your specific needs.

I understand the rationale behind coding standards and we have similar rules effective (regarding the curly braces). But that is not the point, I was up to.
You effectively proposed an if without the braces. Why? Does that not violate the intent of the coding standard you agreed upon? What about

foo() ?> 
    do_work();
    do_other_work_conditionally();

Doesn't have that code the same problem as

if (foo())
    do_work();
    do_otherwork_conditionally();

So, perhaps you want a more concise syntax for a lot of things (exception handling, conditional execution, looping?) That's why a DSL came to my mind...

[johndv7]

foo() ?> 
    do_work();
    do_other_work_conditionally();

Sure, but if your standard limits you to non-compound statements, then that problem is easy to spot and everyone is happy.

So, perhaps you want a more concise syntax for a lot of things (exception handling, conditional execution, looping?) That's why a DSL came to my mind...

That's quite a leap to go from "hey, here's a cool feature we would find helpful" to "you obviously want to change everything, so go make your own language." We like C#.

[martin-steinhoefer]

foo() ?> 
    do_work();
    do_other_work_conditionally();

Sure, but if your standard limits you to non-compound statements, then that problem is easy to spot and everyone is happy.

That is equally true for the if statement - isn't it? An if statement without curly braces limits you to non-compound statements too.

And doesn't MISRA say, that every branch in an if must be a block statement (i.e. the curly braces are mandatory) - for a reason? The rationale behind that is, that it is explicitly clear, which statement belongs to which branch - because that eliminates ambiguity for a human reader.
Your proposal effectively circumvents that particular MISRA rule - doesn't it?

If you want a new syntax for a non-compound if, then you have to show the benefit - explicitly. Not only for you - for everyone (or at least the vast majority of users). Otherwise I guess, the team will reject the idea...

[martin-steinhoefer]

That's quite a leap to go from "hey, here's a cool feature we would find helpful" to "you obviously want to change everything, so go make your own language." We like C#.

Fair enough. But you introduced the different aspects of the discussion. From that I deduced, that you are at least (a little bit) "unhappy" with the current state of error handling and the proposed alternatives on one side and with conditional execution on the other side. To me that looked more like "I really want something different, more concise".

It's not necessarily a whole own language. Maybe there is a solution based on a library of extensions or code generation - I don't know.

[johndv7]

That is equally true for the if statement - isn't it? An if statement without curly braces limits you to non-compound statements too.

Human nature. One of the things that we're really sensitive to is that it's much easier to get it right if "if" always has braces, and some other notation never has braces. Now you don't even have to think about it. So that's why we'd be OK with it.

Fair enough. But you introduced the different aspects of the discussion. From that I deduced, that you are at least (a little bit) "unhappy" with the current state of error handling and the proposed alternatives on one side and with conditional execution on the other side. To me that looked more like "I really want something different, more concise".

It's not necessarily a whole own language. Maybe there is a solution based on a library of extensions or code generation - I don't know.

Maybe? I'm not even sure it's about being concise, though that's part of it. It's really about being more expressive, and part of that is getting rid of all the distractions that aren't really adding anything useful. I'm not talking about useful to the language. I'm talking about useful to me, the human, and to the problem I'm solving.

We've toyed with code generators before they added default implementations to interfaces. It was the same kind of problem. I need a bunch of classes to support an interface, and they implement it exactly the same way. So my solution: build a helper class that does all the real work, and then some short cut & paste boiler plate that implements the interface on the class using the helper. And I hate this kind of witch doctor stuff...say all these magic words, wave your hands theatrically over your keyboard, and voila. So we eventually built a generator to do it.

And then we got default implementations, and we've tossed all of that out.

Extensions is what I do now, like in my original post. It works....quite well, actually. I'm able to toss out countless piles of error checks, and I don't really care about the performance hit of the exception-catch-return because the errors mostly never happen. We almost always take the happy path, and it's brain dead simple to read and write in that style IF the particular problem is really just "do a bunch of steps in this order...but stop if something goes wrong." And a lots of problems are really like that.

I do still think something similar to a ternary would be very useful.