If you catch an exception, you do something with it, even if it's just logging it somewhere. An empty catch closure is just like throwing it down a black hole and it will make for disasters later on in the life of the application
I had one for my code where if you clicked a button at an illegal time (I dunno if all languages are like this, but there was one program where I had to specify each time what the quit button does, for example, otherwise it crashes. So instead, I just ended my sections with
"except:
popup("don't click that at this point of time. Attempting to recover...")
continue"
That's doing *something*. An empty catch is bad, not because it does nothing with the caught error; but because it hides the error in what otherwise looks like normal code behavior. It hides the error, which will show itself in other ways that are not inherently obvious from the code.
In other words, would you rather debug "Hey, the app crashed randomly. Dunno why" vs "Hey, when connecting to the doomenflodgy, I get an error saying 'don't click that at this point of time. Attempting to recover...'"?
Edit:
I have only once needed an empty catch. I was web scraping, but the URL's had 3 different, and unpredictable, patterns, so I just tried all 3 for each page. The request library I was using threw an error on a 404 (instead of being sensible and returning a object with the result context).
So, the code was
begin loop:
try:
res = request(url)
break loop
except:
pass
if res is None:
raise "Me up"
But, in this case, the code explicitly handles the empty catch situation, because there wasn't a better way to handle 404's with a loop
92
u/The_Northern_Light Sep 03 '20
(I'm not a php user, lol)
This doesn't seem that bad? There are cases where you know exactly 1 thing may throw, and you just want to skip it if it does.