Hey Jakub,
On 19.11.2025 23:58:57, Jakub Zelenka wrote:
On Wed, Nov 19, 2025 at 5:37 PM Bob Weinand <[email protected]> wrote:
On 19.11.2025 12:52:35, Jakub Zelenka wrote:
The code one should be probably named StreamErrorCode (to not
interact with what Jordi proposed) and think it will need to be
backed as there should be a straightforward way how to compare it
with exception code. I might need to extend the gen stub as I'm
not sure it allows macro import for enum value like for constants
or I will need to come up with some mapping. I just don't wan to
duplicate the numbers. I will figure something out.
How important is it to have exception code?
I think the exception code could be quite useful for checking for
specific errors. It's much better than trying to match it by error
message which I saw in past used in normal error handlers. So I can
see definitely use case for that. It might be also possible to group
those erors if enums are used so users could just match specific group
of errors.
For the purpose of grouping it would be vastly preferable to add
functions to the enum class to mark enum values as pertaining to
specific groups "function isIoError(): bool", "function
isFileSystemError(): bool" etc. or just simply "function errorGroup():
StreamErrorGroup" which is another enum with some grooups like "Io",
"Filesystem" etc. rather than comparing ranges.
I found that for our purposes we generally skip the exception code
(i.e. keep it at zero).
As a simple example, ErrorException does take two integers - one
for severity, and one for code, instead of using the severity as code.
Severity is almost always warning which I don't think is a good
representation for code. I saw error codes used in various application
and I think they are useful. I don't think it hurts to have them. The
implementation of that enum should not be a big problem. I just need
to figure out how to make it nice.
I would propose something similar here: call it StreamError and
provide a public $error property for the actual enum, rather than
squeezing it into $code.
I'm not sure I understand this. The code is a generic identifier for
the error class that can be matched. StreamError would be the actual
representation containing the message and other info - this cannot be
matched in a generic way.
My point here is that $code generally does not get used for our
Exceptions. Whenever we need to attach extra information to an
exception, we do it as extraneous properties. (That's what my example
with ErrorException was about.)
I.e. ignore the existence of $code (just assign zero).
And add an extra property for the StreamError enum (which now needs no
backing).
class StreamException extends Exception {
public __construct(
public StreamError $error,
public string $wrapperName,
string $message = "",
public string|null $param = "",
?Throwable $previous = null
) {
parent::__construct($message, 0, $previous);
}
}
Does this make more sense, described as code?
Thank you,
Bob
