Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97440
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.163 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAOv67gteeLC1MCwKEZDaiRcUbAt4mqJE7dtBy9QY7+jxs6XJiw@mail.gmail.com>
References: <CAOv67gteeLC1MCwKEZDaiRcUbAt4mqJE7dtBy9QY7+jxs6XJiw@mail.gmail.com>
Date: Sun, 18 Dec 2016 14:09:27 +0100
Message-ID: <CANUQDCifOb3gtkq5nc9nmTmSNAvZ2bX83mc+3eU0U16gKHaP+w@mail.gmail.com>
To: Wes <netmo.php@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c06ca524d3f570543ee83dd
Subject: Re: [PHP-DEV][RFC][DISCUSSION] - Throwables error code's type generalization
From: me@kelunik.com (Niklas Keller)

--94eb2c06ca524d3f570543ee83dd
Content-Type: text/plain; charset=UTF-8

2016-12-18 10:38 GMT+01:00 Wes <netmo.php@gmail.com>:

> Good morning nice internals PHPeople,
>
> I have just written a new RFC. I believe is mostly about cosmetic changes,
> as what is being proposed is probably already informally supported by PHP.
>
> I would like your opinion about it:
> https://wiki.php.net/rfc/throwable-code-generalization
>
> Thank you.
>

+1 from my side. Currently exception codes hardly see any use. Nobody wants
to invent some codes that have to be documented and are hard to remember.
Instead, most people just extend their exceptions to subclasses. But what
if the code comes from external software? It's fine for MySQL, because
MySQL provides numeric error codes. But a lot of software is now talking to
remove APIs. To my experience, most of them use non-numeric error codes,
simply because they're human-readable.

I don't think we should allow objects there, objects are hardly codes. But
allowing string|int would be great for usage with many APIs and make $code
actually useful again.

--94eb2c06ca524d3f570543ee83dd--