Fix chained exceptions serializing as empty JSON objects

[jamisonbryant]

Closes #163

Summary

The exception chain collector in MixerApiExceptionRenderer stored raw Throwable objects in the exceptions viewVar. Since PHP's Exception class has only protected properties and does not implement JsonSerializable, json_encode produced {} for each entry. This wraps each exception in a SerializableException that extends Exception and implements JsonSerializable, preserving the Throwable contract for event listeners while producing structured JSON output.

Major Changes

• Add SerializableException class that extends Exception and implements JsonSerializable, wrapping each exception in the chain to produce structured JSON while remaining a Throwable
• Include file and line when debug is enabled, consistent with how the renderer already handles trace/origin data for the primary exception
• Cap exception chain traversal at 10 iterations to guard against circular chains

Minor Changes

• Remove unused CakeException import from MixerApiExceptionRenderTest
• Use strict comparison (!==) in the chain-walking loop

Backwards Compatibility Notes (superseded)

This changes the type of the exceptions viewVar from Throwable[] to array[] (array of associative arrays). Two considerations:

• JSON output: Changes from [{}, {}] to [{"class": "...", "message": "...", "code": ...}, ...]. The previous output was a serialization bug (empty objects), so no consumer could have been meaningfully depending on it.
• Event listeners: Any listener on MixerApi.ExceptionRender.beforeRender that accesses $viewVars['exceptions'] and calls Throwable methods on the entries (e.g., $e->getMessage()) would need to update to array access (e.g., $e['message']). The ErrorDecorator itself is a passive container and is unaffected.
• Production mode: debugViewVars() unsets the exceptions key entirely when debug = false, so production output is unchanged.

Backwards Compatibility Notes (updated)

The exceptions viewVar entries are now SerializableException instances instead of raw Throwable objects. SerializableException extends Exception (and therefore implements Throwable), so:

• Event listeners: Any listener on MixerApi.ExceptionRender.beforeRender that calls Throwable methods (getMessage(), getCode(), getFile(), getLine()) on chain entries continues to work unchanged. These methods return the original exception's values.
• JSON output: Changes from [{}, {}] to structured objects with class, message, code (plus file and line in debug mode). The previous output was a serialization bug -- json_encode on Throwable produces empty objects because Exception properties are protected.
• instanceof checks: $e instanceof \Throwable and $e instanceof \Exception still pass. Checks for specific exception types (e.g., $e instanceof RuntimeException) would not match, since entries are now SerializableException wrappers. This is unlikely to affect real consumers.
• Production mode: debugViewVars() unsets exceptions entirely when debug = false, so production output is unchanged.

Work Remaining

None.

Test Plan

• Run vendor/bin/phpunit plugins/exception-render/tests/ -- all 21 tests pass
• Run full suite vendor/bin/phpunit -- all 102 tests pass
• Run vendor/bin/phpstan analyse plugins/exception-render/src/ -- no errors

[cnizzardini]

@jamisonbryant the PR description is bigger than the code change (not counting test coverage) ....Can you you give me the tweet version?

[cnizzardini]

Hard for me to tell reading the AI description in here exactly how breaking of a change this is... @jamisonbryant

Is your AI agent saying this is only breaking with debug enabled?

[jamisonbryant]

@jamisonbryant the PR description is bigger than the code change (not counting test coverage) ....Can you you give me the tweet version?

Tweet version (no AI): MixerAPI's exception renderer passes raw Throwable objects to JsonView for chained exceptions, but PHP's Exception class doesn't implement JsonSerializable so they all serialize as {}. Suggested fix is to extract the fields into plain arrays before serialization.

[cnizzardini]

Hard for me to tell reading the AI description in here exactly how breaking of a change this is... @jamisonbryant
Is your AI agent saying this is only breaking with debug enabled?

You're absolutely right! (lol jk) But seriously - I argued a bit with the agent before submitting this PR to really understand the B.C. consequences. Here is my understanding, summarized:

1. The `exceptions` viewVar changes from `Throwable[]` to an array of associative arrays. The JSON output changes from `[{}, {}]` to structured objects with class, message, and code keys (plus file and line when debug is enabled).

2. The previous output was a **serialization bug** (emphasis mine). `json_encode` on `Throwable` objects produces empty objects because Exception properties are protected. No consumer could have been meaningfully depending on `{}` entries. If I'm wrong, please lmk!

3. The one potential impact is event listeners on `MixerApi.ExceptionRender.beforeRender` that access the `exceptions` viewVar and call methods e.g., `$e->getMessage()` would need to switch to array access instead.

P.S. I know B.C. is important, so I added a new section to my PR templates at the bottom to address exactly this question. If that information is unclear, can you let me know so I can tweak it?

1. Is maybe breaking.
2. Not worried about this
3. Seems breaking.

[cnizzardini]

I'm just brainstorming here and this may be one of or both of a misuse and overkill, but what if a class was created that implements Throwable and JsonSerializable. Wouldn't this become backwards compatible?

[jamisonbryant]

PHP won't let you implement Throwable:

Fatal error: Class Foo cannot implement interface Throwable, extend Exception or Error instead

I got around this by doing exactly that: extending Exception.

[cnizzardini]

Interesting. I had never tried myself either. Good work. This looks promising I will hopefully have time this week to pull it down and validate things myself.

[jamisonbryant]

Thanks Chris! Any chance you can give me minimal privileges to approve workflows (GitHub Actions) on your repos? So I can at least verify pipelines are green?

I run the tests as I write code but sometimes CI behaves funny so it would be nice to know :)

[cnizzardini]

I think once you are contributor (i.e. this PR is merged) it will auto-run them. It's just restrictive for first-time contributors.

[jamisonbryant]

I can clean up those style errors lickety split in just a bit.