feat: nullable exception handlers

[maximvlah]

Closes #3776

[greptile-apps]

Greptile Summary

This PR introduces nullable exception handlers for both frontend and backend error handling in the Reflex framework. The changes allow users to explicitly set exception handlers to None to disable custom exception handling, which is particularly useful for Kubernetes liveness and readiness probes where standard HTTP error responses are preferred over custom error handling logic.

The implementation modifies two core files:

In reflex/app.py:

• Updates type annotations for frontend_exception_handler and backend_exception_handler to include | None
• Modifies validation logic to skip validation when handlers are None
• Adds a null check before executing the backend exception handler

In reflex/state.py:

• Adds null checks in the _process_event method before calling backend_exception_handler
• Adds null checks in the handle_frontend_exception method before calling frontend_exception_handler

The change maintains full backward compatibility since the default handlers are still provided, but adds flexibility for cloud-native deployments where infrastructure monitoring systems need predictable error responses. This fits into the broader Reflex architecture by extending the existing exception handling system without breaking existing functionality, allowing apps to have optional exception handlers that can be conditionally disabled based on deployment context.

Confidence score: 4/5

• This PR is safe to merge with minimal risk as it maintains backward compatibility while adding useful functionality
• Score reflects well-structured null safety checks and non-breaking changes to existing exception handling
• Pay close attention to the validation logic in reflex/app.py to ensure the skip condition works correctly

_{2 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}

[codspeed-hq]

CodSpeed Performance Report

Merging #5703 will not alter performance

_{Comparing maximvlah:set-none-to-exception-handler (7ceac10) with main (9b2d93e)}

Summary

✅ 8 untouched benchmarks

[maximvlah]

@masenf @benedikt-bartscher ready for review

[adhami3310]

it would be a tad better to check with is not None just in case a Var might come here, otherwise looks good!

[maximvlah]

@adhami3310 thx, just fixed it

[adhami3310]

the only issue is that this doesn't disable the frontend onError from triggering, it just that when it goes to the backend, it does nothing

[benedikt-bartscher]

the only issue is that this doesn't disable the frontend onError from triggering, it just that when it goes to the backend, it does nothing

That was the original intention/idea in #3776. Can you adjust it @maximvlah?

onError would still trigger, just the backend will do the equiv of lambda _: None, so nothing would meaningfully change for that

it's quite difficult to pipe the logic through the default error handler :/

[masenf]

seems fine to me, are we wanting to disable the entire frontend exception handling mechanism if the handler is None? because that's definitely more work

[adhami3310]

i think to truly resolve the associated ticket, we do want to actually disable onError