Fix misleading error messages with {capture}

[ichaykin]

Fixes #1032

What does this fix?

This fixes misleading error reporting when an exception is thrown while rendering content inside a {capture} block.

Before this change, the original render exception could be hidden by a later CaptureRuntime::endRender() exception:

Not matching {capture}{/capture}

That made debugging harder, because the developer had to remove or inspect the {capture} block to find the real error.

What changed?

Template::render() now keeps track of an exception thrown during the actual render phase.
The endRenderCallbacks are still executed in finally, preserving the cleanup behavior. However, if rendering has already failed and an endRenderCallback also throws, the callback exception no longer replaces the original render exception.
If rendering succeeds, callback exceptions keep the previous behavior and are still thrown normally.

Behavior after this change

• If rendering fails inside {capture}, the original render exception is reported.
• If rendering succeeds but an endRenderCallback fails, that callback exception is still reported.
• If both rendering and an endRenderCallback fail, the original render exception wins.

[Copilot]

Pull request overview

This PR fixes misleading error reporting when rendering fails inside a {capture} block by preventing exceptions thrown during end-of-render cleanup (endRenderCallbacks) from masking the original render-time exception in Template::render().

Changes:

• Track a render-time exception and ensure endRenderCallbacks run in finally.
• Preserve prior behavior where endRenderCallback exceptions are still thrown when rendering succeeds.
• When both render and cleanup fail, prefer the original render exception.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.