4 ms·
"None capturing catch blocks" 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 har
by mekster 4y ago
"None capturing catch blocks"
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.
- ramesh31 4y agoThis 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?
- tyingq 4y agoAlso, often you don't need more info. Like in some contexts, dividebyzero...you have all you need.
- nobleach 4y agoJavaScript 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".
- mfonda 4y agoThis 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.
- ryangittins 4y ago> Not sure how this feature made its way in. It's possible the language was just following usage rather than leading it. Regardless of whether or not it's right, I commonly see something like } catch (\Exception $e) { // no-op }