Convert SPL Exception usage to normal Error

[Girgias]

It seems to be me that it is wiser to convert those Exceptions to (Type|ArgumentCount|Value)Error then to leave the SPL Exceptions.

Thoughts?

[Girgias]

If there are no objections I'll merge this in a week.

[nikic]

@cmb69 @kocsismate Any thoughts on the general idea here? Changing existing exception types seems somewhat more problematic from a BC perspective to me, and not sure it really buys us much.

[kocsismate]

At the first sight, this change seemed too risky for me, but I am wondering if it is really the case:

As far as I saw, these are programming errors. Thus, I would be surprised if people caught the thrown exceptions "directly".

What it means for me is that it might not matter much for the end users what kind of exception is actually thrown... And as people already have to have a general error handler (catching Throwables) since years, we wouldn't even risk their production system by throwing previously uncatchable/unknown exceptions.

[kocsismate]

All these returns should be RETURN_THROWS() ideally. See #5036

[Girgias]

Huh, I though that you went through them that's why I needed to manually fix the merge conflicts. Will do the remaining ones

[kocsismate]

Ah, no, please ignore. I didn't add RETURN_THROWS() previously myself here, because it's not sure that an exception is thrown. But then what is the purpose of changing the return type?

[Girgias]

I didn't look at the specific case until I opened my editor. But yeah now I'm not sure why I changed the return type ...

[cmb69]

Maybe

if (do_throw) {
    RETURN_THROWS();
} else {
    RETURN_FALSE;
}

[Girgias]

I think I've covered all the case, please let me know if there are some that I missed.

[kocsismate]

For me, the PR itself looks fine (apart from the few issues with RETURN_THROWS()), but we should try to address Nikita's concern. :)

[Girgias]

Should I move forwards with this, post on internals, or drop this change?

[Girgias]

Any other opinions?

[cmb69]

Thinking about this, it seems to me that it's more of a problem that we still support some of these exceptions not to be thrown at all (spl_autoload_register(…, false)). While that may have made sense when the function had been introduced, I don't think it makes sense for PHP 8, where most other functions now throw (instead of warn) on illegal input. I think I'd start there.

[Girgias]

Thinking about this, it seems to me that it's more of a problem that we still support some of these exceptions not to be thrown at all (spl_autoload_register(…, false)). While that may have made sense when the function had been introduced, I don't think it makes sense for PHP 8, where most other functions now throw (instead of warn) on illegal input. I think I'd start there.

SPL is truly an interesting extension, I didn't even know you could do that. Are there only a couple of function which toggle this behaviour, and if so is there a list? (could always read the docs to get an idea of haw many there are ...)

[cmb69]

spl_autoload_register() may be the only such function. (And yes, SPL is "interesting".)

[Girgias]

I've made some conversions too while I was updating the errors to the new format, don't know if I should have split or not but the easiest would be to split per Class if needed.

@kocsismate can you have a look at the error messages?

Also still need to do iterators and observers classes.

[kocsismate]

@Girgias I'll have a look for sure! However, I think we should first decide if we can really change the exceptions to errors. @nikic? @cmb69? I for one would be in favour, because this is what we use everywhere (with the exception of sodium, as far as I can tell).

However, I don't know much about the BC implications... My guess is that the change wouldn't be very problematic, since I would expect that people generally don't catch InvalidArgumentExceptions separately... (but just in the outmost exception handler)

[cmb69]

Well, we also have to consider existing test suites; I'm not sure that changing the exception types is a good idea for now.

[kocsismate]

we also have to consider existing test suites

Yes, that makes sense. In this case, some of the zend_(type|value)_error() invocations could be changed to zend_argument_error(exception_ce, ...)

[Girgias]

Closing because this is old and rebasing it is a bit of a PITA. Might reopen a similar one just converting Uninitialized/already initialized objects to a standard Error.