Since when do you not need the actual error object in the catch clause? The example is one of a bad habit of making debugging hard by not telling what exactly happened. Maybe it timed out, maybe the connection was refused, or maybe it returned 404 but I guess the author doesn't care what the detail is making it harder to reach the source of the problem.
This information is often communicated by the type of the exception itself. Maybe it timed out: TimeoutException. Maybe the connection was refused: ConnectionRefusedException. Maybe it returned 404: NotFoundException.
Depending on the specifics of how it's handled, you may or may not need the actual error message. For example, in production you may want to implement some sort of logic (retry, display friendly error message, etc.), none of which needs the actual error message.
This feature isn't unique to PHP. Other languages with Exceptions, for example C# and C++, have this exact same feature.
JavaScript did that too in the last couple of years. It's thoroughly confusing that we'd want to catch an exception and toss away all knowledge of WHAT exception was thrown. Unless one really just wants to log, "bad things happened".
This happens all the time. You're doing something risky, which has no consequence to the rest of the system if it fails. Sure you could catch it and log it out, but why?
Since when do you not need the actual error object in the catch clause? The example is one of a bad habit of making debugging hard by not telling what exactly happened. Maybe it timed out, maybe the connection was refused, or maybe it returned 404 but I guess the author doesn't care what the detail is making it harder to reach the source of the problem.
Not sure how this feature made its way in.