Add Method to UnhandledMatchError to get the Unhandled Value

[donatj]

Description

When catching a failed match it would be very handy if the UnhandledMatchError had a method such as getUnmatchedValue() : mixed that contained the actual unmatched value.

This could allow more graceful handling of failed match handlers.

This would allow as a very basic example:

function getTypeName( mixed $value ) : string {
    return match (gettype($value)) {
        'integer', 'double' => 'number',
        'string'            => 'string',
        'NULL'              => 'null',
    };
}

try {
    getTypeName($item);
} catch(\UnhandledMatchError $e) {
    $log->info("Received unhandled type: " . $e->getUnmatchedValue());
}

I'm sure there is more involved handling you could do with it as well.

@derickr advised me to open a ticket for this idea

[iluuu1994]

Hi @donatj! Thanks for the suggestion. I'm not personally in favor, because 1. I don't believe you should generally catch \Errors, which makes the value uninteresting, and 2. we don't do this for any other ValueErrors. The value itself is also already embedded in the message. But let's see what others think.

[donatj]

Thanks you for the feedback. I do, however, disagree that you shouldn't catch errors.

Why would PHP move from warnings to errors to if not to make them more easily catchable/handleable? Being able to catch them is particularly useful I find in reflection/inspection - especially in cases where you code is running someone else code that might not be perfectly formed. Providing as much info as possible helps others fix issues more efficiently.

Catching errors allows for graceful error handling, and adding helpful detail only serves makes it more useful.

For ValueError, I could actually argue having the specific parameter that failed would also be very useful, though probably out of scope here.

Open to more thoughts on this.

[iluuu1994]

Why would PHP move from warnings to errors to if not to make them more easily catchable/handleable?

Fatal errors are very harsh, and warnings are error prone because they don't terminate control flow. With exceptions you can handle generic errors gracefully in your front controller and display an error message accordingly. I don't think catching specific errors makes much sense, because if you know your code can throw errors, you should fix the code. Of course, you can't know about all errors in advance, but then you also don't know about its type (is it a UnhandledMatchError, ValueError, or whatnot).

Note that this reasoning is exactly what we use to determine whether something internally should throw an error or an exception: Do we expect users to want to catch them, or is the problem unrecoverable? For the former, we use exceptions, and for the latter we use errors.

Do you have a use case other than logging? Because then the value is already visible in the error message (if it is inspectable, that is). If providing more information is the goal, maybe this is better solved by improving error messages in all places, so all users can benefit.

[Girgias]

I agree with @iluuu1994 here, I'm not really in favour of adding such capabilities.

The Error hierarchy is for programming errors that can be prevented at runtime, the advantage of using the exception mechanism instead of bailout is that destructors are run, finally blocks are executed, the stack is unwound properly, etc.

Some more rationale about this can be found in the original RFC to convert bailouts to Exceptions. [1]

As one of the main people that converted E_WARNINGs to ValueErrors for PHP 8.0 was the added return type clean-up we could do.
Indeed, a lot of functions/methods only returned false/null for programming level errors, and so now you don't need to branch on an unlikely unexpected return value. However, many E_WARNINGs remain as the issues they point to cannot be prevented in advance as they depend on the environment or runtime conditions.

[donatj]

Well if no one is interested, we can probably close this.

[iluuu1994]

Do you have a use case other than logging?

If logging is the only use-case, feel free to close this issue 🙂

[github-actions]

No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.