This entire post is dedicated to using the wrong tool for the job…
Use isset if you want to see if the variable is set, you should never be casting client input unless it’s coming from query params (or form post I guess but at that point use JSON).
“empty” is a useful tool, provided you take into account things like “is this allowed to be 0/empty-string/etc”.
Lastly:
> After a lengthy debugging session, we realized that empty() was treating 0 as "empty", causing our validation to fail unexpectedly.
Lengthy? To notice an empty check failing? Look, the codebase I work on has its warts, all older codebases do, but unless you have no XDebug, forgot how to log to file or echo to the client, and/or aren’t capable of searching a codebase for the error you got and tracing it back from there then I can’t believe that would be a “Lengthy” process to track down. Even if you are returning a generic error to the client, surely you are logging the real error to a log somewhere?
It's a common mistake that newcomers to the language make. You assume empty is an empty string check when it's really a falsy check that is equivalent to: (!isset($var) || !$var)
it's not always that straight forward to connect xdebug to where you need it, especially if that is triggered by some API call from external uncontrolled system. if that error could just trigger some generic error like product/entry/item is invalid so you would have no idea with exact condition failed. finally there in e-commerce offer there are import processes that get thousands of products in single batch, logging will get very messy and getting to that one product that had issue might take some time in each run
we had some errors that were happening to only one client and noone could reproduce that.
If you want to find sane function naming, PHP is only going to disappoint you. I say that as someone who likes PHP, the old function names (and argument order) are… not great.
isset is like is_null but one thing isset can do is look at a whole chain (class props or associate array keys) and not blow up.
Use isset if you want to see if the variable is set, you should never be casting client input unless it’s coming from query params (or form post I guess but at that point use JSON).
“empty” is a useful tool, provided you take into account things like “is this allowed to be 0/empty-string/etc”.
Lastly:
> After a lengthy debugging session, we realized that empty() was treating 0 as "empty", causing our validation to fail unexpectedly.
Lengthy? To notice an empty check failing? Look, the codebase I work on has its warts, all older codebases do, but unless you have no XDebug, forgot how to log to file or echo to the client, and/or aren’t capable of searching a codebase for the error you got and tracing it back from there then I can’t believe that would be a “Lengthy” process to track down. Even if you are returning a generic error to the client, surely you are logging the real error to a log somewhere?