Try, catch, and using

Saving a checkpoint can fail, and a temporary resource still needs cleanup. Exception handlers make those uncommon paths visible beside the normal one, and a using node marks where a resource is scoped.

The problem

A method that opens a resource, performs work, catches one expected failure, and always cleans up has several kinds of ownership. Reading only the happy path hides the handler and cleanup that keep the method safe.

When to reach for it

Use a try/catch/finally node when a block handles exceptions. Each catch clause records its exception type, optional variable, optional filter, and body. A using statement appears as one Using node that carries its resource declaration and stands in for the whole block; the statements inside it are not drawn. await using has its own node with a resource input, an output named for the declared variable, and the body statements after it.

A catch filter becomes a condition gate on that handler path. A bare throw; inside catch is a rethrow node. The finally path runs cleanup as execution leaves the handler shape.

See it

The try/catch family uses #CD6133; using uses #2E86C1. Labels and scope paths carry the meaning when color is unavailable.

Do it

1. Open a method containing try. Follow execution into the try body before reading the handler paths.

2. Read each catch clause in source order. The node exposes exception variables as typed outputs when the clause names one.

3. For a filtered catch, follow the filter condition. A true result enters the handler; false lets exception matching continue.

4. Follow finally separately. Treat it as cleanup attached to every way execution leaves the protected shape.

5. Right-click an authored handler and choose Edit Catch Clauses to add, remove, reorder, or change clauses supported by that graph-owned structure. Parsed handlers expose their clauses in the inspector; changing clause structure is limited to handlers authored on the canvas.

6. For a using statement, read the resource declaration on the Using node, then continue from its exec output to the statement after the block. Edit the block itself in C#.

You should see

You can name the normal path, each matching handler, the filter that gates it, and the cleanup that runs on exit.

Change one thing

Read a handler from the outside in: resource scope, try body, catch filter, catch body, finally. Then read it in execution order. The two passes expose both ownership and control flow.

What it writes

C#

What it writes

C#

try
{
    A();
    if (c)
    {
        B();
    }
    D();
}
catch (System.Exception ex) when (ex.Message.Length > 0)
{
    E();
}
catch (System.Exception)
{
    F();
}
finally
{
    G();
}

Catch clause order, type, variable, filter, and body come from the handler. Finally is emitted only when that path exists. Round Trip does not write a using statement: a Compile that has to regenerate a body containing one refuses with a using statement and leaves the file unchanged.

When it goes wrong

When it goes wrong

Symptom	Check	Fix
Edit Catch Clauses is missing.	Check whether the handler was parsed from source or authored on the canvas.	Edit parsed clause structure in source, or create a graph-owned handler when visual clause authoring is required.
A catch filter never enters its body.	Trace the bool feeding the filter condition.	Correct the condition or the values wired into it.
Cleanup appears on only one visible path.	Find the finally output instead of following one catch body alone.	Keep shared cleanup in finally so every exit from the handler runs it.

Next

• Return and throw: see throws and rethrows that terminate a path.
• When it refuses: understand unsupported handler shapes.
• Nodes, pins, and wires: review specialized node family colors.