Hi Bob, On Thu, Nov 20, 2025 at 1:11 AM Bob Weinand <[email protected]> wrote:
> 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. > > > Yeah that's what I was thinking. Internally I would still probably represent it as num ranges (as it is now) but userspace should use those enum functions. > 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? > As I see what you mean now. I would prefer to use StreamError name for the class holding all the details including code, wrapper name, message and param as proposed by Jordi because this could be also passed to handler and retrieved from the stored errors. It just seems not right to use StreamException as a container without being thrown (is that done anywhere?) so I think separate class for handler and stored errors (or single last error) seems cleaner. Although StreamException would be then quite similar. I could pass StreamError there as a property but then it would duplicate the message so not sure. In any case I think it's better to call that enum StreamErrorCode. I will still find a clean way to map it to the defines (STREAM_ERROR_CODE_* macros) because that's what I use internally to set code in the error. So not using int value for the exception code won't make that much difference from the implementation PoV. Kind regards, Jakub
