On Thu, May 1, 2025, at 7:47 AM, Juris Evertovskis wrote:
> On 2025-04-29 17:29, Matthew Weier O'Phinney wrote:
>
>>
>> * Exceptions should not be used for normal application logic flow. If the
>> "error" is recoverable and/or expected, use a different mechanism so you can
>> use standard conditional branching.
>>
>> As such, there are a lot of situations where I may not want to use
>> exceptions. Two common ones:
>>
>> * Input validation. In most cases, _invalid input is expected_, and a
>> condition you will handle in your code. Exceptions are a really poor
>> mechanism for this.
>> * "Not found" conditions, such as not finding a matching row in a database
>> or a cache. Again, this is expected, and something you should handle via
>> conditionals.
> I don't want to make this into a quarrel, please consider this to be a
> genuine question — I'm trying to understand the viewpoint behind the
> need for such "failed result" channel.
>
> I'm considering this scenario: An update request comes into a
> controller and passes a superficial validation of field types. The
> 'troller invokes an action which in turn invokes a service or whatever
> the chain is. Somewhere along the call stack once all the data is
> loaded we realize that the request was invalid all along, e.g. the
> status can't be changed to X because that's not applicable for objects
> of kind B that have previously been in status Z.
>
> In such situations I have found (according to my experience) the
> following solution to be a good, robust and maintainable pattern:
>
> Once I find the request was invalid, I throw a ValidationException. No
> matter how deep in the stack I am. No matter that the callers don't
> know I might've thrown that. The exception will be caught and handled
> by some boundary layer (controller, middleware, error handler or
> whatever), formatted properly and returned to the user in a
> request-appropriate form.
>
> I currently have no urge to return an indication of invalidity manually
> and pass it up the call stack layer by layer. Should I want that? In my
> experience such patterns (requiring each layer to do an `if` for the
> possible issue and return up the stack instead of continuing the
> execution) get very clumsy for complex actions. Or have I misunderstood
> the usecase that you had in mind?
>
> BR,
> Juris
The key distinction is here:
> Somewhere along the call stack once all the data is
> loaded we realize that the request was invalid all along
combined with:
> No matter that the callers don't
> know I might've thrown that.
Addressing the second part first, unchecked exceptions means I have no idea at
all if an exception is going to get thrown 30 calls down the stack from me.
Literally any line in my function that calls anything could be the last. Is my
code ready for that? Can it handle that? Or do I need to put a try-finally
inside every function just in case?
Admittedly in a garbage collected language that concern is vastly reduced, to
the point most people don't think about that concern. But that's not because
it's gone away entirely. Are you writing a file and need to write a terminal
line to it before closing the handle? Are you in the middle of a DB
transaction that isn't using a closure wrapper for auto-closing (which PDO
natively does not)?
Technically, if you're writing this code:
$pdo->beginTransaction();
foreach ($something as $val) {
$write = transform($val);
$pdo->query('write $write here');
}
$pdo->commit();
That's unsafe because transform() might throw, and if it does, the commit()
line is never reached. So you really have to put it in a try-catch-finally.
(Usually people push that off to a wrapping closure these days, but that
introduces extra friction and you have to know to do it.)
Or similarly,
$fp = fopen('out.csv', 'w');
fwrite($fp, "Header here");
foreach ($input as $data) {
$line = transform($data);
fputcsv($fp, $line);
}
fwrite($fp, "Footer here");
fclose($fp);
If transform() throws on the 4th entry, you now have an incomplete file written
to disk. And *literally any function you could conceive of* could do this to
you. The contract of every function is implicitly "and I might also unwind the
call stack 30 levels at any time and crash the program, cool?"
You are correct that unchecked exceptions let you throw from way down in the
stack if something goes wrong later. Which brings us back to the first point:
If that's a problem, it's a code smell that you should be validating your data
sooner. This does naturally lead to a different architectural approach. Error
return channels are an "in the small" feature. They're intended to make the
contract between one function and another more robust. One can build a
system-wide error pattern out of them, but they're fundamentally an
in-the-small feature.
So in the example you list, I would offer:
1. Do more than "superficial validation" at the higher level. Validate field
types *and* that a user is authorized to write this value (for example).
2. As discussed, we do need some trivially easy way to explicitly defer an
error value back to our caller. That should be easy enough that it's not a
burden to do, but still explicit enough that both the person reading and
writing the code know that an error is being propagated. This still requires
research to determine what would work best for PHP.
Wouldn't the heavy use of error return channels create additional friction in
some places and cause us to shift how we write code? Yes, grasshopper, that is
the point. :-) The language should help us write robust, error-proof code, and
the affordances and frictions should naturally nudge us in that direction.
Just as explicit typing makes certain patterns less comfortable and therefore
we move away from them, and are better for it.
--Larry Garfield
