>
> Er. Except that's not true. PHP itself throws exceptions only in two
> very specific cases:
>
> * PDO, if configured to do so.
> * random_int()/random_bytes(), if no entropy source can be found.
>
Hrm. Must've been working inside frameworks too long. Of course PHP
doesn't throw exceptions - it didn't even have them for the longest time.
Point ceded, proposal withdrawn.
As noted before, a failed type check in PHP 5 is equivalent to
>
> trigger_error('error message', E_RECOVERABLE_ERROR).
>
> In PHP 7, it's equivalent to
>
> throw new TypeError(...);
>
> (TypeError implementing Throwable, but not being a descendant of
> \Exception.)
>
> See:
>
> https://3v4l.org/XL0Of
>
> Neither of those are InvalidArgumentException.
>
Yeah, errors in both cases...
The spec very explicitly says that cache failures must be non-fatal to the
> application. Throwing uncaught exceptions is fatal to the application. In
> fact, the spec explicitly says that exceptions from the underlying engine
> (PDO, file system, Redis, whatever) must be caught and normalized to just a
> normal cache failure so that it's non-fatal.
>
> Remember, we're talking about a very narrow problem space: Passing a
> non-DateTimeInterface object to a method that expects one. There are no
> conditions where that is anything other than the programmer screwing up,
> probably very very close to the call itself. (eg, if you call
> expiresAt('2016-07-29'), then according to the spec you're just wrong and
> should fix your damned code. <g>)
>
If only PHP < 5.5 didn't need to be supported, this discussion wouldn't
even be taking place, because type hinting would make PHP handle this for
us instead. (Or if the PHP devs had made DateTimeImmutable extend
DateTime, even that wouldn't have been an issue - but then libs relying on
getting DateTime objects could be handed DateTimeImmutable objects instead,
and fail spectacularly. Oh well.) Exceptions do make the most sense
during development to force developers to notice coding errors, but since
we need to avoid issues in production, and the PSR doesn't specify that any
exceptions can be thrown there, I do think our hands are rather tied.
> If the spec were still subject to change then I'd be more open to
> InvalidArgumentException, as the class does throw that explicitly in a few
> other places (that are also "Developer, you're just wrong" cases). As this
> is just an errata, however, I don' think throws are on the table.
>
The Errata *might* still need to be updated to clarify whether throwing
\Errors is acceptable, as they aren't \Exceptions, but \Throwables of a
different kind. My guess is they aren't acceptable either, given the
reasoning behind prohibiting exceptions (lower case, which also leans
toward all \Throwables) in the first place.
--Larry Garfield
>
My only real concern is that with assertions disabled, invalid arguments
will cause other issues in the lib, with no way for the lib to catch and
properly handle them internally - because the lib is relying on the
assertion to do that for it. Mimicking a type error may be a better option
in this case, since these invalid values "MUST be treated as an invalid
syntax error"...
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/aae32146-efa3-4ae6-8496-b17c34c71a45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
