On Wed, 30 Apr 2025 at 21:13, Larry Garfield wrote:
> >> […] just that it's the only time I've seen $code used in the wild...
> >>
> >
> > PDO (for better or worse) also uses the `$code` for the error code
> > returned by the database. Unfortunately it also widens the (untyped)
> > $code from int
On Wed, Apr 30, 2025, at 1:06 PM, Tim Düsterhus wrote:
> Hi
>
> On 4/30/25 15:33, Larry Garfield wrote:
>> The only time I've seen anyone use $code is in TYPO3. Their coding
>> standards say that any time you throw an exception, you use the current
>> timestamp (determined manually) as a code.
Hi
On 4/30/25 13:18, Derick Rethans wrote:
- Exceptions MUST NOT be ``final``.
Could the RFC explain why not?
I'm not sure if this is useful to add to the RFC itself as a “only extra
explanation” and since the discussion is an equally official resource:
The reason is to allow flexible exte
Hi
On 4/30/25 15:33, Larry Garfield wrote:
The only time I've seen anyone use $code is in TYPO3. Their coding standards
say that any time you throw an exception, you use the current timestamp
(determined manually) as a code. That way there is a globally unique code
regardless of exception t
On Wed, Apr 30, 2025, at 6:18 AM, Derick Rethans wrote:
> On Sun, 27 Apr 2025, Tim Düsterhus wrote:
> - Any two exceptions with different causes MUST be identifiable either
> by a unique exception class name, a stable ``$code``, or a
> class-specific additional property suitable for programm
On Sun, 27 Apr 2025, Tim Düsterhus wrote:
> Hi
>
> as announced in the URI RFC discussion thread
> (https://externals.io/message/123997#127142), I've now written up an
> “Exception Hierarchy” policy RFC together with Gina.
>
> Please find the following links:
>
> RFC: https://wiki.php.net/rfc/e
Hi
On 4/29/25 00:36, Larry Garfield wrote:
It's a common recommendation in userland, as it allows implementers to extend
an existing exception (eg, InvalidArgumentException) of their choice while
still being tagged as coming from a given library. Though I suppose if the
policy doc also says
On Mon, Apr 28, 2025, at 4:27 PM, Tim Düsterhus wrote:
> Hi
>
> On 4/28/25 23:09, Larry Garfield wrote:
* Would allowing an extension-tagging interface instead of a base class be
an option? It still allows for catching "anything thrown by this
extension", which I presume is the go
Hi
On 4/28/25 23:09, Larry Garfield wrote:
* Would allowing an extension-tagging interface instead of a base class be an option? It
still allows for catching "anything thrown by this extension", which I presume
is the goal. If not, why?
See the “Choice of Base Exception” section in
https:/
On Mon, Apr 28, 2025, at 3:30 PM, Tim Düsterhus wrote:
> Hi
>
> On 4/28/25 22:04, Larry Garfield wrote:
>> Holy cow, thank you for this bit. The inability to tell what went wrong
>> programmatically without string parsing the exception message is one of my
>> biggest pet peeves in current except
Hi
On 4/28/25 22:04, Larry Garfield wrote:
Holy cow, thank you for this bit. The inability to tell what went wrong
programmatically without string parsing the exception message is one of my
biggest pet peeves in current exceptions.
Anything particular from the standard library? It might be
On Sun, Apr 27, 2025, at 4:45 PM, Tim Düsterhus wrote:
> Hi
>
> On 4/27/25 23:16, Kamil Tekiela wrote:
>> The exception message MUST NOT be the only means of distinguishing
>> exceptions. Any two exceptions with different messages MUST be
>> identifiable either by a unique exception class name or c
Hi
On 4/27/25 23:16, Kamil Tekiela wrote:
The exception message MUST NOT be the only means of distinguishing
exceptions. Any two exceptions with different messages MUST be
identifiable either by a unique exception class name or code.
Thank you. I have used that as the basis for this change:
h
>Do you have a wording suggestion to make it clearer what is meant by
that sentence?
How about this:
The exception message MUST NOT be the only means of distinguishing
exceptions. Any two exceptions with different messages MUST be
identifiable either by a unique exception class name or code.
On Sun, Apr 27, 2025, at 22:40, Kamil Tekiela wrote:
> >The exception message MUST NOT be the only property that allows to
> differentiate different types of error that the user may be interested in.
>
> What does this mean exactly? Can you give an example?
>
Many people don’t know about the $
Hi
On 4/27/25 22:40, Kamil Tekiela wrote:
The exception message MUST NOT be the only property that allows to
differentiate different types of error that the user may be interested in.
What does this mean exactly? Can you give an example?
This is intended to say “if a user calls ->getMessage(
>The exception message MUST NOT be the only property that allows to
differentiate different types of error that the user may be interested in.
What does this mean exactly? Can you give an example?
Hi
as announced in the URI RFC discussion thread
(https://externals.io/message/123997#127142), I've now written up an
“Exception Hierarchy” policy RFC together with Gina.
Please find the following links:
RFC: https://wiki.php.net/rfc/extension_exceptions
Policy PR: https://github.com/php/pol
18 matches
Mail list logo
