Allow Throwable to be extended outside of Exception

[robincafolla]

Description

At present \Throwable cannot be directly extended. If you try to it throws a Fatal error:

PHP Fatal error: Class FakeException cannot implement interface Throwable, extend Exception or Error instead in /censored/path/to/FakeException.php on line 7

This makes sense for the vast majority of use cases; it prevents people from re-inventing the wheel and trying to implement Throwable when really they should just extend Exception.

However, there are cases where extending Throwable would make sense, particularly in light of the fact that all methods on Exception are final.

For example, tests for exception handling and logging code can't mock Exceptions fully or sensibly. Testing that your log messages are being correctly written to log storage is difficult to make repeatable.

There are 3 solutions to this problem:

1. Allow \Throwable to be extended
2. Make final methods in \Exception non-final to allow stubs to over-ride existing behaviour
3. Add a new class specifically for tests which implements Throwable and can be extended to stub behaviour

I think that option 1 is the simplest. We should rely on the docs to tell people to extend Exception, but allow Throwable to be implemented.

[bwoebi]

While the methods are final, the properties can be trivially set via reflection. (And mostly, the methods just return those.)

[iluuu1994]

From the Throwable RFC:

https://wiki.php.net/rfc/throwable-interface

The proposed patch does not allow userland classes to implement the Throwable interface. Instead all classes declared in userland must extend one of the existing exception classes.

Exception and Error are distinct classes of exceptions. Exception is used for anticipated errors, i.e. things the user should guard for. Error is used for programming mistakes that should generally never be caught. It is currently safe to assume that handling both of them handles all exceptions.

Changing how this works should be discussed in an RFC.

[mvorisek]

I do not think implementing Throwable directly should be allowed neither. I miss to find the strong reason why and also it will imply huge BC break as a lot of code assumes the Error/Exception only.

What I however support is to remove the final from the methods. My usecase is to store some backtrace references using WeakReference and return the backtrace without WeakReference (with real objects if they are still alive).

[robincafolla]

Apologies for the long reply delay.

@bwoebi that's a good work-around at present, but it doesn't address the design issue.

@iluuu1994 the distinction is sensible. Doubling the work on testing \Throwable via \Exception and \Error is a compromise I'm willing to make, but sadly you still can't easily mock either of those classes; since their methods are final.

How does that second option sound? make the methods of \Exception and \Error non-final?

[iluuu1994]

How does that second option sound? make the methods of \Exception and \Error non-final?

I think that's a less controversial change, but should probably still be discussed on the internals mailing list. You can propose the change and ask for objections, and if not send a PR. If there are objections, this will need an RFC.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.