Why Verse Fails #1 — Failure Is a Feature

Overview

Here's a secret about Verse that no tutorial ever leads with: the compiler rejecting your code is the language working correctly. Verse has no null. It has no exceptions. Instead, it has failure — a first-class idea baked into the language — and a compiler that refuses to let a possibly-failing question go unanswered.

Picture a vault door on your island. Players collect keys; the door should open only for a key-holder. Every interesting thing in that sentence — does this player have a key?, is there a first key in the list?, is the door locked right now? — is a question that might come back empty. Verse makes you say, in the shape of your code, what happens when it does. The compiler errors you'll meet in this lesson aren't the language fighting you. They're the language asking: and what if not?

This is the first lesson of Why Verse Fails — a series taught from real compiler errors, captured from real builds on the real UEFN compiler. You'll meet each error exactly as it appears in your own Verse output log, learn to read what it's actually saying, and fix it for a reason you understand.

The question the whole lesson answers

When a Verse expression might fail, it may only appear in a failure context — a place in the code that has a plan for the failure. You already know the most common one: the condition of an if. The compiler will name the others for you shortly — in its own words.

Let's break the vault three ways.

Wall 1 — asking for a key that might not exist

The vault's key names live in an array. We want the first one:

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }

vault_keys_a := class(creative_device):
    KeyNames : []string = array{"Rusty Key", "Coral Key", "Gold Key"}

    OnBegin<override>()<suspends> : void =
        FirstKey := KeyNames[0]
        Print("The first key is {FirstKey}")

Looks harmless. The compiler disagrees:

Script error 3512: This invocation calls a function that has the 'decides' effect, which is not allowed by its context. The 'decides' effect indicates that the invocation calls a function that might fail, and so must occur in a failure context that will handle the failure. Some examples of failure contexts are the condition clause of an 'if', the left operand of 'or', or the clause of the 'logic' macro.

Read it slowly, because this error is a free lesson. Indexing an array — KeyNames[0] — might fail: the array could be empty. In Verse, "might fail" is called the decides effect, and an expression that carries it must sit somewhere with a failure plan. A bare assignment on its own line has no plan. And notice the gift at the end: the compiler literally lists the places that do — the condition clause of an if, the left operand of or, the clause of the logic macro.

So we give the question a home:

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }

vault_keys_a := class(creative_device):
    KeyNames : []string = array{"Rusty Key", "Coral Key", "Gold Key"}

    OnBegin<override>()<suspends> : void =
        if (FirstKey := KeyNames[0]):
            Print("The first key is {FirstKey}")

if (FirstKey := KeyNames[0]): asks and answers in one motion — if there is a first key, name it FirstKey and come inside. Empty array? The if simply doesn't take the branch. No crash, no null check, no exception. The failure had a plan.

Wall 2 — round brackets on a question

Now the door check. We write a little function that decides whether a player holds enough keys, and we call it:

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }

vault_keys_b := class(creative_device):
    HasKey(KeyCount : int)<decides><transacts> : void =
        KeyCount > 0

    OnBegin<override>()<suspends> : void =
        if (HasKey(1)):
            Print("The vault opens")

The compiler:

Script error 3511: This call uses parentheses to call a function that has the 'decides' effect. Functions that may fail, which is indicated by the 'decides' effect, must be called with square brackets, while functions that always succeed must be called with parentheses.

This one is pure vocabulary, and it's worth locking in forever: in Verse, the brackets tell the truth about failure. Round brackets () are for calls that always succeed. Square brackets [] are for calls that might fail — anything marked <decides>. The call site is honest about what it's calling; a reader can see the risk without opening the function.

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }

vault_keys_b := class(creative_device):
    HasKey(KeyCount : int)<decides><transacts> : void =
        KeyCount > 0

    OnBegin<override>()<suspends> : void =
        if (HasKey[1]):
            Print("The vault opens")

One character pair changed — HasKey[1] — and it compiles. Notice the shape of HasKey itself while we're here: a <decides> function doesn't return true or false. Its body is the test — KeyCount > 0 — and succeeding or failing IS the answer. That's why it slots straight into an if.

Wall 3 — comparing states outside a failure context

The door has a state, and we'd like a quick flag for whether it's locked:

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }

door_state := enum{Locked, Open}

vault_keys_c := class(creative_device):
    var State : door_state = door_state.Locked

    OnBegin<override>()<suspends> : void =
        IsLocked : logic = State = door_state.Locked
        Print("Checked the door")

The compiler again refuses — with the same error 3512 you met at Wall 1:

Script error 3512: This invocation calls a function that has the 'decides' effect, which is not allowed by its context. The 'decides' effect indicates that the invocation calls a function that might fail, and so must occur in a failure context that will handle the failure. Some examples of failure contexts are the condition clause of an 'if', the left operand of 'or', or the clause of the 'logic' macro.

Surprised? Here's the reveal: in Verse, = is not a boolean operator — comparison is itself a question that can fail. State = door_state.Locked succeeds if they're equal and fails if they're not, which means it carries the decides effect, which means it needs a failure context — and the right-hand side of a plain assignment isn't one.

The idiomatic fix isn't to manufacture a flag at all. Ask the question where questions belong:

The comparison lives in the if condition — a failure context — and both outcomes get a branch. This is the pattern you'll use a hundred times: don't store the answer to a failable question; ask it where the failure has a plan.

The mental model to keep

• Failure is control flow, not catastrophe. Verse replaced null and exceptions with one idea: expressions that might fail, handled in places that expect failure.
• <decides> marks the questions. Array indexing, map lookup, = comparison, your own <decides> functions — all questions.
• [] calls a question, () calls a certainty. The brackets at the call site tell the reader the truth.
• Failure contexts are the places with a plan. The if condition is your workhorse; the compiler's own error text lists the rest.
• The compiler is telling the truth. Error 3512 means "you asked a question with no plan for no." Error 3511 means "your brackets lie about the risk." Fix the reason, not the symptom.

Where this goes next

Everything in this series builds on today's model. Next lesson: the effects system — <decides> is one of a family of function contracts, and the compiler enforces all of them just as strictly. The vault door isn't done with us yet.