When a failed guard condition raises an immediate failure, that’s called a contract precondition. The general rule I’m familiar with is “return and clean up if the guard might be false, throw an error if the guard shouldn’t be false.”

You’re right, in most cases you’ll need to throw in a guard clause instead of return. You only return when failed preconditions means you don’t need to do any actions, not can’t do. Like deleting a resource when it doesn’t exist.

Might place more requirements on both lang and lib than you were asking for, but I’ve been messing with a reterr (return error) keyword in my language Tiko that works alot like Rust’s try! macro/? operator.

Tiko uses an Option instead of null, so

func doThing(x Option<T>) {
    reterr x
    fmt.Println("only reached if not null!")
}

desugars into

func doThing(x Option<T>) {
    match x {
      None => return
    }

    fmt.Println("only reached if not null")
}

reterr returns on any falsey expression, any Result<T, E> that is an Error, and any empty Option<T>. Anything else continues through. It will also pass the error up from Result iff the func’s type signature returns an Error.

I like it alot. It makes for some VERY clean code that reads declaratively but doesn’t seem out of place in the imperative style. Preconditions and Go-like if err != nil { return err } handling are readable but don’t take up the majority of visual space on screen.

I worry because it does quite alot of things. It blesses Result and Option, plus it just happens to work with falsey expressions which aren’t necessarily errors. It’s got utility, but not exactly the greatest in terms of aesthetics from a language design standpoint. reterr and return are also super similar visually and might be confused/missed. Since this is mainly a toy language it’s mostly just me having fun and I haven’t had much issue with it so maybe I’m just too hesitant to commit ;)

It’s definitely not a new idea (mostly ripped off from rejected ideas in the Rust ? operator RFC) but given your comment I thought it might be interesting enough to merit a reply.

Some languages (like lisps/schemes) have when and unless. (when foo bar ...) is similar to if (foo) { bar ... }, (unless foo bar ...) is like if (foo) {} else { bar ... }.

ensure is probably one of the better terms to use for this. I might steal this!

I personally like unless keyword, though unfortunately it’s not present in Java. Also one I really liked (maybe most) is a pattern-matching-like approach I saw in Erlang:

execute_timer(entity) when entity /= null ->
    sound_alarm(entity);
execute_timer(_) ->
    do_nothing.

Swift has the guard statement.

Here is a rough translation of the function in the linked article.

func run(timer : Timer) throws
{
    guard timer.enabled else {
        return
    }
    guard timer.valid else {
        throw InvalidTimerException()
    }
    timer.run()
}