Skip to content

Common - Isolate PFH errors - #1821

Open
DarkBall123 wants to merge 1 commit into
CBATeam:masterfrom
DarkBall123:common-isolate-pfh-errors
Open

Common - Isolate PFH errors#1821
DarkBall123 wants to merge 1 commit into
CBATeam:masterfrom
DarkBall123:common-isolate-pfh-errors

Conversation

@DarkBall123

@DarkBall123 DarkBall123 commented Jul 12, 2026

Copy link
Copy Markdown
Contributor

When merged this pull request will:

  • Keep later PFHs and frame queues running when one PFH errors.

used the isNil suggestion from the issue so one broken PFH no longer stops the rest. ScriptError and the stack trace are still reported normally.

tested this with persistent and one-off errors, nested handlers, self-removal, adding and removing handlers during iteration, return values and delayed handlers. later handlers and frame queues kept running after an error, and the largest measured overhead was about 0.16 ms with 500 PFHs.

image

Fixes #1602

@DarkBall123
DarkBall123 marked this pull request as ready for review July 12, 2026 11:47
@DartRuffian

Copy link
Copy Markdown
Contributor

Comment saying why it's there would probably be good

@PabstMirror

Copy link
Copy Markdown
Contributor

What if we modify CBA_fnc_addPerFrameHandler to optionally wrap
that way there is no performance penalty for most users

params [["_function", {}, [{}]], ["_delay", 0, [0]], ["_args", []], ["_iWriteShitCode", false, [false]]];

if (_iWriteShitCode) then {
    _function = compile format ["isNil {%1}", toString _function];
};

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PerFrameHandler Framework Issue: Stuck Handler Prevents Execution of Subsequent Handlers

4 participants