I’ve seen this done with an error-handler before, it’s quite useful - particularly because exceptions come with a stack trace, which makes for more useful error messages.
Code that produces E_WARNING tends to be poorly written, so I would agree that throwing exceptions for trapped errors/warnings is a good approach. E_STRICT could also be thrown, as it’s usually an indication that you’re writing code for an older version of the PHP language.
Notices on the other hand are sometimes just helpful information for the developer - I would not suggest you throw those, but rather I would prefer an option that allows me to pass those to a Logger.
One big issue with handling errors in this way, is the fact that legacy code and third-party libraries frequently produce E_WARNING - short of hacking vendor-supplied libraries, there wouldn’t be much you can do to work around that fact. Unless we have an option to disable throwing for specific classes.
Another thing that custom error-handlers of this type frequently get wrong, is the error-suppression operator - if implemented, this must be supported and work as expected, as it’s an integral part of the language.
It seems like there are so many ways to do this, it’s tempting to make this error-handler highly configurable - but that would be both good and bad, since you would have to “learn”, on every project you work on, how errors are handled for that specific project, and potentially you’ll end up with modules/components that require a particular error-handling configuration, which could cause trouble when attempting to integrate modules/components into an application.
Also keep in mind the risk and learning-curve involved when changing standard PHP behavior. That’s not necessarily a deterrent, when you’re changing things for the better, but it does require a level of awareness or will to learn about differing conditions as compared to vanilla PHP code and/or other frameworks…