3 ms·
That code is never acceptable. Don't catch all exceptions just to log and continue. That's like Visual Basic's On Error Resume Next sprinkled with logging! Now,
by jansommer 5y ago
That code is never acceptable. Don't catch all exceptions just to log and continue. That's like Visual Basic's On Error Resume Next sprinkled with logging! Now, you could instead catch a specific exception, a caught exception, log it, and write a very detailed comment on why you're only logging and not rethrowing, so the reviewer doesn't have to ask.
- xg15 5y agoAh, I see what you mean. Yes, if it's about recovering from a particular error, that would be for specific exceptions. There are some cases where you basically have to make your own top-level error handling - for example in (java) worker threads. An uncaught exception would either terminate the thread or would be swallowed without showing up anywhere.
- jansommer 5y agoI think the flamewar algo is preventing me from replying to your message xg15, but yes, it totally makes sense to have a global error handler on threads. I think that though the original article sounds like it is never okay, I don't imagine the author is against corner cases such as global error handlers in web frameworks, threads, browsers and so on. I just wish developers would refraign from writing try catch 80% of the time, because it pretty much always boils down to only a logging call and perhaps a generic error response that the framework would take care of anyway (at least in ASP.NET).