On Fri, Aug 14, 2015 at 12:24 PM, Davey Shafik <davey@php.net> wrote:
> > So from this POV it is good, IMO. Namely, to know that it is the concrete
> case delivering the concrete exception type instead of abstract Exception,
> IntlException, PharException, etc. The chosen exception class name might
> make you think that it's like enforcing strict mode, but that's not the
> case. Hm, so question is - are exception class names really bound to
> whether strict mode is used or not?
>
> I don't disagree with this on principle, consistency is good, but now we
> actually have LESS consistency because the constructor can throw one of
> many exceptions. For example, PDO can throw a \TypeError or a \PDOException
> on connection failure, or if the constructor fails in some other way. This
> leads to code like this:
>
> try {
> new PDO([]);
> } catch (\TypeError $e) {
>
> } catch (\PDOException $e) {
>
> }
>
> With the potential for duplication in the error handling (in both catch
> blocks), OR code like this which is overly generic and will potentially
> catch other random stuff:
>
> try {
> new PDO([]);
> } catch (\Throwable $e) {
> // must be throwable as it's the only common thing between \TypeError
> and \PDOException
> }
>
> This is why I say the previous behavior should be preserved: Warning for
> type mis-match, with a (in this case) \PDOException if the constructor
> fails (possibly as a result of the mis-match, or for any other reason)
> UNLESS strict types are on, then a \TypeError should be thrown, and it
> wouldn't attempt to execute the constructor and no \PDOException would be
> thrown.
>
> This then gives us the following flow:
>
> try {
> new PDO([]); // Warning, array given, string expected
> } catch (\PDOException $e) {
> // maybe connection failed, or constructor failed because we passed an
> array!
> }
>
> OR we enable strict types and you basically need the examples shown
> originally, but at least that's a conscious choice and expected behavior.
>
> I believe that the goal should be: don't surprise your users, and this
> change fails that. The new behavior is not what I think most people would
> expect coming from 5.x, and that is a bad thing.
>
Why do you have an expectation that a function should throw one exception
type and one type only? It is customary that different causes for an
exception will also result in different exception types. Here TypeError is
thrown if a wildly inappropriate type is passed, say an array instead of a
string. A PDOException on the other hand is thrown if some failure specific
to PDO's domain occurs, say a non-existing socket or invalid user name. A
programmer wishing to catch a PDOException is unlikely to be interested in
catching the kind of error that TypeErrors signify.
The motivation behind using TypeError here is twofold. Firstly, it is an
error type that exists specifically to be thrown for zpp failures.
Secondly, and more importantly, this avoid throwing different exception
types between weak and strict mode. If we didn't throw TypeError here, then
switching from weak to strict would change what was previously a
PDOException to a TypeError -- which I would consider to be rather
unexpected and suboptimal.
Nikita
> > So from this POV it is good, IMO. Namely, to know that it is the concrete
> case delivering the concrete exception type instead of abstract Exception,
> IntlException, PharException, etc. The chosen exception class name might
> make you think that it's like enforcing strict mode, but that's not the
> case. Hm, so question is - are exception class names really bound to
> whether strict mode is used or not?
>
> I don't disagree with this on principle, consistency is good, but now we
> actually have LESS consistency because the constructor can throw one of
> many exceptions. For example, PDO can throw a \TypeError or a \PDOException
> on connection failure, or if the constructor fails in some other way. This
> leads to code like this:
>
> try {
> new PDO([]);
> } catch (\TypeError $e) {
>
> } catch (\PDOException $e) {
>
> }
>
> With the potential for duplication in the error handling (in both catch
> blocks), OR code like this which is overly generic and will potentially
> catch other random stuff:
>
> try {
> new PDO([]);
> } catch (\Throwable $e) {
> // must be throwable as it's the only common thing between \TypeError
> and \PDOException
> }
>
> This is why I say the previous behavior should be preserved: Warning for
> type mis-match, with a (in this case) \PDOException if the constructor
> fails (possibly as a result of the mis-match, or for any other reason)
> UNLESS strict types are on, then a \TypeError should be thrown, and it
> wouldn't attempt to execute the constructor and no \PDOException would be
> thrown.
>
> This then gives us the following flow:
>
> try {
> new PDO([]); // Warning, array given, string expected
> } catch (\PDOException $e) {
> // maybe connection failed, or constructor failed because we passed an
> array!
> }
>
> OR we enable strict types and you basically need the examples shown
> originally, but at least that's a conscious choice and expected behavior.
>
> I believe that the goal should be: don't surprise your users, and this
> change fails that. The new behavior is not what I think most people would
> expect coming from 5.x, and that is a bad thing.
>
Why do you have an expectation that a function should throw one exception
type and one type only? It is customary that different causes for an
exception will also result in different exception types. Here TypeError is
thrown if a wildly inappropriate type is passed, say an array instead of a
string. A PDOException on the other hand is thrown if some failure specific
to PDO's domain occurs, say a non-existing socket or invalid user name. A
programmer wishing to catch a PDOException is unlikely to be interested in
catching the kind of error that TypeErrors signify.
The motivation behind using TypeError here is twofold. Firstly, it is an
error type that exists specifically to be thrown for zpp failures.
Secondly, and more importantly, this avoid throwing different exception
types between weak and strict mode. If we didn't throw TypeError here, then
switching from weak to strict would change what was previously a
PDOException to a TypeError -- which I would consider to be rather
unexpected and suboptimal.
Nikita