Hacker News Reader

Comment by matthewrhoden1 | Hacker News Reader

It looks really weird to me, having that empty catch block. I expect a lot of issues to accidentally be introduced from poor merges or something.

View on HN

I don't understand. Why would you have an empty catch block? He does in his example but that's an example. I cannot see why you'd even write a catch block if it was empty in production code (unless you're trying to do some error-and-continue pattern, which is rare/mostly an anti-pattern).

I wish it were rare, I've seen it in a lot of projects I've had the privilege of dropping in on. They will often check for an error and log it, then "throw;".

edit: to further clarify my objective, I was thinking of a way to make the stack traces better, without risking the maintainability of the code now that I'm aware of the difference. I guess in all it would be best to just remove it. In my case, we've found some strange things in unexpected places and I prefer to not change stuff, unless I understand how the underlying portions work.

Or just supress it, for some methods you might want to return a null value/"null object"/bool rather than have an exception cascade up the chain and risk crashing the application. I think Exceptions are a bit problematic as a concept but then again so are null values :)

An easy example are checking if a file exists under Windows 8, it's partly a product of the currently deficient API's but the fastest way to check if a file exists is to try to get it and catch the exception, and you'd want to return bool from a FileExists method

After many years I still don't really grok the idea behind exceptions, and I get this feeling that I'm not alone with that. There probably is an extremely smart idea supporting this whole "handle all errors with exceptions" style, but I haven't seen any good explanation yet; instead what I see most often is a case of Stockholm syndrome - "it's in the language, it's The $LANGUAGE Style, it must be Good!".

Reply on news.ycombinator.com